tml@tik.vtt.fi (Tor Lillqvist) (02/17/91)
I am trying to compile Andrew (patchlevel 9) with the new C compiler on the Series 300. I have trouble with the dynamic loading auxiliary program doindex, which complains "unknown symbol type." Debugging reveals that the r_segment field of a relocation record in an object file being indexed has the value 4, which seems to be something that the new compiler (actually the peephole optimizer) started producing. Substituting the old /lib/c2 pass avoids the problem, as does compiling without optimization. Another alternative is going back to using gcc. What is this relocation segment 4? Is there possibly somebody who knows how one should handle it in doindex?... -- Tor Lillqvist, working, but not speaking, for the Technical Research Centre of Finland
mjs@hpfcso.FC.HP.COM (Marc Sabatella) (02/20/91)
> I am trying to compile Andrew (patchlevel 9) with the new C compiler > on the Series 300. I have trouble with the dynamic loading auxiliary > program doindex, which complains "unknown symbol type." Debugging > reveals that the r_segment field of a relocation record in an object > file being indexed has the value 4, which seems to be something that > the new compiler (actually the peephole optimizer) started producing. > > Substituting the old /lib/c2 pass avoids the problem, as does > compiling without optimization. Another alternative is going back to > using gcc. I would recommend against using the old /lib/c2 with the new compiler - it can't be guaranteed to work, and we can't support it. At the very least, you'll be missing out on instruction scheduling and other goodies. I would also recommend against gcc, but of course I'm biased :-) Relocation type 4 is new for 7.40, and specifies "PC relative" relocation. The #define to be added to /usr/include/a.out.h is "#define RPC 04". It works a lot like REXT - the symbolnum field is an index into the symbol table for an unresolved reference, and the address field contains a location within the segment to patch. But instead of plugging in the value of the symbol, you plug in the displacement from the location itself to the symbol. This relocation type is produced to allow "bsr" and "bra" instructions to cross module boundaries. For the 68040, "bsr" is faster than "jsr". A quick workaround that doesn't require modifying the Andrew source code would be to run the output of the original /lib/c.c2 through a "sed" script that simply replaced all occurences of "jsr" with "bsr". Another workaround is to compile with "-W2,-x" - passing the "-x" option to c2 tells it not to optimize for the 68040, which will prevent the "bsr's" from being generated. But it is easy enough to do the fixup yourself. With REXT, the pseudo code for the fixup is *address += symtab[symbolnum].n_value in other words, add the value of the symbol the current contents of the location. With RPC, the pseudo code is *address += symtab[symbolnum].n_value - address in other words, the displacement from the location itself to the symbol is added to the current contents of the location. If the code you are loading is fully resolved - that is, contains no unresolved external references, possibly being produced by a previous invocation of "ld", then there should be no need for RPC relocations to remain in the object file. This was an oversight on our part, and has already been fixed for future releases (the r_segment is changed to "RNOOP"). If you are currently dealing with REXT records, then you can add the RPC handling as I have described. Do not apply if the symbol being reference is defined in the same module, because that it was already applied during the "ld -r" run. If you were not otherwise dealing with REXT records, it must be because you expected everything to have already been fully resolved, meaning you can continue to ignore the symbol table and safely assume all RPC records are bogus and ignore them too. -------------- Marc Sabatella (marc@hpmonk.fc.hp.com) Disclaimers: 2 + 2 = 3, for suitably small values of 2 Bill and Dave may not always agree with me