[comp.soft-sys.andrew] A second step closer to plumber on AIX.

wdc@ATHENA.MIT.EDU (Bill Cattey) (10/02/90)

I extracted calloc.o from libc.a and ran the 'dis' program on it.  This
helpful utility either provides assembly language disassembly of a .o
file or hangs in an infinite loop.  This time, it gave me a recognizable
.s file for calloc.o

Look at the two symbols:  %_Djyj.Q and%_Sjyj.Q as they appear in my calloc.s:


%_Djyj.Q:
        .long     %_Sjyj.Q
%_Sjyj.Q:
        .byte     0x40        /'@'
        .byte     0x28        /'('
        .byte     0x23        /'#'
        .byte     0x29        /')'
        .byte     0x63        /'c'
        .byte     0x61        /'a'
        .byte     0x6c        /'l'
        .byte     0x6c        /'l'
        .byte     0x6f        /'o'
        .byte     0x63        /'c'
        .byte     0x2e        /'.'
        .byte     0x63        /'c'
        .byte     0x9
        .byte     0x31        /'1'
        .byte     0x2e        /'.'
        .byte     0x31        /'1'
        .byte     0x30        /'0'
        .byte     0x9
        .byte     0x41        /'A'
        .byte     0x49        /'I'
        .byte     0x58        /'X'
        .byte     0x0
        .byte     0x0
        .byte     0x0

It's an identifier string generated by either the C compiler, the
loader, or the library archive program.

How nice.
And it's global so anyone can find it.
And it's global so getlist.awk wants it.
I wonder how the symbol name was generated...

Does anyone have a suggestion how we might modify getlist.awk to
carefully discard such symbols so that we don't force loading of
routines we're overriding?

-wdc

"If you could push this button and your wife (every PS/2) would
dissappear, would you do it?"

-Jack Lemon (with my amendment)
From "How to Murder your Wife"

wjh+@ANDREW.CMU.EDU (Fred Hansen) (10/05/90)

Excerpts from internet.info-andrew: 2-Oct-90 A second step closer to
plu.. Bill Cattey@ATHENA.MIT.E (1706)


> Does anyone have a suggestion how we might modify getlist.awk to
> carefully discard such symbols so that we don't force loading of
> routines we're overriding?

The original message is a great piece of work, finally getting to the
heart of the problem.  

The solution, it seems to me, is that the set of modules processed by
getlist.awk should include the itc malloc and exclude the system malloc.
 If such an approach is made to work, we'll release it in a forthcoming
patch.

Fred Hansen

pgc+@ANDREW.CMU.EDU ("Paul G. Crumley") (10/05/90)

Hello,

The idea of removing the system malloc routines and replacing them with
the ITC malloc routines sounds like one way to attack this problem.  I
don't think it is a general solution as there are bound to be other such
symbols lurking about in libc.a, libcrt0, etc.

If you want to try this there are a few things you should know.

1)  Check the configuration files to make sure that the ITC malloc is
being constructed on your system.
2)  If malloc wasn't being constructed find out why.  (i.e. does it work?)
3)  This is probably just a temporary patch until another weird symbol
bites you.

When I started the RT/AIX 2.2.1 port I found that the PL.8 based
compiler used to construct many of the libc modules inserted a number of
strange symbols.  (Yes, IBM used a compiler with better optimization for
it's interal work.)  Unless the construction of libcx for class has
changed in the last year you should be able to see where a bunch of
symbols are discarded in the RT/AIX version.  If you can find out who is
generating the offending symbols you should be able to attack the
problem at the source with a similar script.


Best of Luck,

Paul