This is the mail archive of the
mailing list for the binutils project.
Re: SIGSEGV in ld at elflink.h:5500
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: amodra at bigpond dot net dot au (Alan Modra)
- Cc: binutils at sources dot redhat dot com
- Date: Fri, 26 Jul 2002 13:37:23 -0400 (EDT)
- Subject: Re: SIGSEGV in ld at elflink.h:5500
> * elf-bfd.h (_bfd_elf32_link_record_local_dynamic_symbol): Define
> as elf_link_record_local_dynamic_symbol.
> (_bfd_elf64_link_record_local_dynamic_symbol): Likewise.
> (elf_link_record_local_dynamic_symbol): Declare. Now returns int.
> * elflink.h (elf_link_record_local_dynamic_symbol): Move to..
> * elflink.c: .. here. Use bfd_elf_get_elf_syms. Check whether an
> attempt is made to record a symbol in a discarded section, and
> return `2' in that case.
> Committing to mainline. This can go to the branch (assuming no
> objections) when the elf64-hppa problem is proven fixed.
The patch fixes the elf64-hppa problem with section symbols in
excluded link once sections. I have also checked the patch with
builds and checks of gcc under hppa-linux and hppa64-hp-hpux11.00.
Thus, if there are no other objections, I would like it on the
branch as well.
I have done some more experimentation with using INIT and FINI
sections on hppa64-hp-hpux11.00. This exposes new problems with
respect to undefweak functions. I hacked around a bit and ld can
now link a program with undefined weak functions. However, I get
the following error when such a program executes:
./gengenrtl -h > tmp-genrtl.h
/usr/lib/pa20_64/dld.sl: Unsatisfied code symbol '__deregister_frame_info' in load module './gengenrtl'.
/usr/lib/pa20_64/dld.sl: Unsatisfied code symbol '_Jv_RegisterClasses' in load module './gengenrtl'.
/usr/lib/pa20_64/dld.sl: Unsatisfied code symbol '__register_frame_info' in load module './gengenrtl'.
/bin/sh: 22331 Killed
These symbols are undefined weak
As far as I can tell, the main difference between the hppa64 executable
and a similar executable on hppa-linux is that we have R_PARISC_FPTR64
relocs for the above. Both have R_PARISC_IPLT relocs for the symbols.
There is also a difference in the type of the symbols (STT_FUNC and
STT_NOTYPE on hppa64 and hppa-linux, respectively) but I don't think
this is the cause of the above. The basic problem is that the HP
linker and dynamic loader don't like unresolved symbols (other than
a few special ones) of any kind (HP added pthread routine stubs to
libc to work around this problem). The HP dynamic loader doesn't
create FPTR relocs. I am wondering if the linker could work around
the above problem somehow.
This issue is how to handle code like:
extern void __register_frame_info (void *, struct object *)
__register_frame_info (__EH_FRAME_BEGIN__, &object);
It would seem that we would have to get rid of the dynamic relocs
and symbol refererences, and zero the pointer to the plabel. I don't
know if this is reasonable. It would make the behavior of the
gnu linker differ from the hp one.
However, first there is another issue. __deregister_frame_info and
__register_frame_info are defined in libgcc.a, so I don't know why
they weren't linked in. They aren't weak.
J. David Anglin email@example.com
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)