To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Christos Zoulas <email@example.com>
Date: 01/22/1999 18:34:56
On Jan 22, 3:23pm, jonathan@DSG.Stanford.EDU (Jonathan Stone) wrote:
| >And shared libraries? I have not gotten that to work yet :-)
| >I still have problems with COPY relocations.
| Once upon a time the R_COPY code was inside #ifdef __alpha__, because
| the relocs werent' defined for mips. Did they get turned on properly
| for i386? Or does the code not work there?
Well the problem is that R_COPY relocations don't seem to work for
either the alpha or the i386. On the alpha there is a comment in
elf64_alpha.c in binutils-1.9.1 that says that COPY relocs are ugly
and we don't need them because we compile everything pic... Well that
does not work with the i386, since even with -fPIC COPY relocs still
get emitted... Also the size of the symbol to be relocated is 0 on
the i386 so that ends up being a noop. I don't understand how linux
can work with broken copy relocations unless they use their own copy
of bfd that has this problem fixed.
| Guess we should add a featuremacro or two, and turn them on inside
| MACHINE_ARCH specific headers, rather than the explicit ifdefs.
We could do that I guess. The ifdefs are not that bad though.
| >I've also kludged the interpreter to load at 0, because otherwise
| >it tries to reference relocatable symbols before it gets a chance
| >to relocate them.
| The alpha has some hand-tweaked assembly that relocates ld.elf_so
| before it starts relocating anything else. Duplicating that seems
| ... painful. Mapping at address 0 breaks null-pointer checking,
| so on mips we mapped ld.elf_so at the high end of a `segment' boundary.
Yes, it is really painful... The mips interpeter loads at 0 for the
same reason I guess from what I see in the source. Are you sure that
we load the mips interpreter at 0.