for the DT_IA64_PLT_RESERVE dynamic table entry. When a shared object
does not have any PLT relocations, the linker apparently doesn't find
it necessary to actually reserve the space for the BOR (Bind On
Reference) entries as pointed to by the DTE. As a result, relocatable
data in the PLT was overwritten, causing some unexpected control flow
with annoyingly predictable outcome: coredump.
To reproduce:
% echo 'int main() { return 0; }' > foo.c
% cc -o foo foo.c -lxpg4
Untested (testing request went unanswered), but sparc64 is not expected to
cause problems. IA64 is not expected to cause problems but the patch was
slightly more complex so the possibility exists.
Approved by: jdp
o Set st_shndx for sym_zero to SHN_UNDEF instead of SHN_ABS.
This gives us something to reliably test against.
o For weak references to undefined sysmbols (as indicated by
having st_shndx equals SHN_UNDEF) in the context of OPDs,
the address of the OPD is to be zero, not the address of
the function it contains.
o For weak references to undefined symbols in all other cases
(only DIR64LSB at this time), the actual relocated value is
to be zero, not the value prior to relocating.
Roughly speaking, weak references to undefined symbols are no-ops.
Tested on: i386, ia64
objects were not being correctly set to zero. Instead, the function
descriptor pointer was set to the load address of the .so object. This
caused gcc generated binaries to segfault on exit when crtbegin.asm's
_fini code tested the __cxa_finalize() function pointer for zero.
This is a bit of a hack because of a problem nearby workaround for
find_symdef and its quirks (failures) for local symbols. This still
needs to be fixed.
DT_INIT and DT_FINI tags pointed to fptr records. In 2.11.2, it points
to the actuall address of the function. On IA64 you cannot just take
an address of a function, store it in a function pointer variable and
call it.. the function pointers point to a fptr data block that has the
target gp and address in it. This is absolutely necessary for using
the in-tree binutils toolchain, but (unfortunately) will not work with
old shared libraries. Save your old ld-elf.so.1 if you want to use
old ones still. Do not mix-and-match.
This is a no-op change for i386 and alpha.
Reviewed by: dfr