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