Re: SIGSEGV in ld at elflink.h:5500

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> bfd/ChangeLog
> 	* 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

                 w __deregister_frame_info
		 w _Jv_RegisterClasses
		 w __deregister_frame_info

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 *)
                                  TARGET_ATTRIBUTE_WEAK;

...

  if (__register_frame_info)
      __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.

Thoughts?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)