Re: SIGSEGV in ld at elflink.h:5500

Re: SIGSEGV in ld at elflink.h:5500

[Alan Modra]

On Thu, Jul 25, 2002 at 12:22:53AM -0400, John David Anglin wrote:
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x400000000004f604 in L$2249 () at ../../src/bfd/elflink.h:5500
> 
> > OK, so it's a section symbol from a removed linkonce section.
> > 
> > I think elf64-hppa.c needs to check for this case before calling
> > _bfd_elf64_link_record_local_dynamic_symbol, with something like
> > 
> > ((sec->flags & SEC_LINK_ONCE) != 0
> >  && bfd_is_abs_section (sec->output_section))
> 
> I traced back the value of "e" associated with the SIGSEGV and find
> that it is added in allocate_dynrel_entries.  I don't think the other
> functions that call _bfd_elf64_link_record_local_dynamic_symbol are
> a problem but I am not entirely certain.
> 
> The approach outlined above doesn't work.  It requires the input section
> for the symbol.  What we have is the owner and input index.  rent->sec->name
> is .eh_frame.  Any thoughts on an easy way to get the input section
> for the symbol?

The standard way is to read and swap in the symbol using
bfd_elf_get_elf_syms, then call bfd_section_from_elf_index on
sym.st_shndx.  However, I'm about to check in the following which
ought to make it easy for you.  In fact, you may not need to change
elf64-hppa.c at all.

Using bfd_elf_get_elf_syms in elf_link_record_local_dynamic_symbol
means we have no structures that change size between ELF32 and ELF64,
so the function can move to elflink.c.

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.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Index: bfd/elf-bfd.h
===================================================================
RCS file: /cvs/src/src/bfd/elf-bfd.h,v
retrieving revision 1.84
diff -u -p -r1.84 elf-bfd.h
--- bfd/elf-bfd.h	23 Jul 2002 11:15:06 -0000	1.84
+++ bfd/elf-bfd.h	25 Jul 2002 06:41:20 -0000
@@ -1558,10 +1558,12 @@ extern Elf_Internal_Rela *_bfd_elf64_lin
 #define bfd_elf64_link_record_dynamic_symbol \
   _bfd_elf_link_record_dynamic_symbol
 
-extern boolean _bfd_elf32_link_record_local_dynamic_symbol
-  PARAMS ((struct bfd_link_info *, bfd *, long));
-extern boolean _bfd_elf64_link_record_local_dynamic_symbol
+extern int elf_link_record_local_dynamic_symbol
   PARAMS ((struct bfd_link_info *, bfd *, long));
+#define _bfd_elf32_link_record_local_dynamic_symbol \
+  elf_link_record_local_dynamic_symbol
+#define _bfd_elf64_link_record_local_dynamic_symbol \
+  elf_link_record_local_dynamic_symbol
 
 extern boolean _bfd_elf_close_and_cleanup
   PARAMS ((bfd *));
Index: bfd/elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.26
diff -u -p -r1.26 elflink.c
--- bfd/elflink.c	4 Jul 2002 14:40:25 -0000	1.26
+++ bfd/elflink.c	25 Jul 2002 06:41:27 -0000
@@ -302,6 +302,98 @@ _bfd_elf_link_record_dynamic_symbol (inf
   return true;
 }
 
+/* Record a new local dynamic symbol.  Returns 0 on failure, 1 on
+   success, and 2 on a failure caused by attempting to record a symbol
+   in a discarded section, eg. a discarded link-once section symbol.  */
+
+int
+elf_link_record_local_dynamic_symbol (info, input_bfd, input_indx)
+     struct bfd_link_info *info;
+     bfd *input_bfd;
+     long input_indx;
+{
+  bfd_size_type amt;
+  struct elf_link_local_dynamic_entry *entry;
+  struct elf_link_hash_table *eht;
+  struct elf_strtab_hash *dynstr;
+  unsigned long dynstr_index;
+  char *name;
+  Elf_External_Sym_Shndx eshndx;
+  char esym[sizeof (Elf64_External_Sym)];
+
+  if (! is_elf_hash_table (info))
+    return 0;
+
+  /* See if the entry exists already.  */
+  for (entry = elf_hash_table (info)->dynlocal; entry ; entry = entry->next)
+    if (entry->input_bfd == input_bfd && entry->input_indx == input_indx)
+      return 1;
+
+  amt = sizeof (*entry);
+  entry = (struct elf_link_local_dynamic_entry *) bfd_alloc (input_bfd, amt);
+  if (entry == NULL)
+    return 0;
+
+  /* Go find the symbol, so that we can find it's name.  */
+  if (!bfd_elf_get_elf_syms (input_bfd, &elf_tdata (input_bfd)->symtab_hdr,
+			     (size_t) 1, (size_t) input_indx,
+			     &entry->isym, esym, &eshndx))
+    {
+      bfd_release (input_bfd, entry);
+      return 0;
+    }
+
+  if (entry->isym.st_shndx != SHN_UNDEF
+      && (entry->isym.st_shndx < SHN_LORESERVE
+	  || entry->isym.st_shndx > SHN_HIRESERVE))
+    {
+      asection *s;
+
+      s = bfd_section_from_elf_index (input_bfd, entry->isym.st_shndx);
+      if (s == NULL || bfd_is_abs_section (s->output_section))
+	{
+	  /* We can still bfd_release here as nothing has done another
+	     bfd_alloc.  We can't do this later in this function.  */
+	  bfd_release (input_bfd, entry);
+	  return 2;
+	}
+    }
+
+  name = (bfd_elf_string_from_elf_section
+	  (input_bfd, elf_tdata (input_bfd)->symtab_hdr.sh_link,
+	   entry->isym.st_name));
+
+  dynstr = elf_hash_table (info)->dynstr;
+  if (dynstr == NULL)
+    {
+      /* Create a strtab to hold the dynamic symbol names.  */
+      elf_hash_table (info)->dynstr = dynstr = _bfd_elf_strtab_init ();
+      if (dynstr == NULL)
+	return 0;
+    }
+
+  dynstr_index = _bfd_elf_strtab_add (dynstr, name, false);
+  if (dynstr_index == (unsigned long) -1)
+    return 0;
+  entry->isym.st_name = dynstr_index;
+
+  eht = elf_hash_table (info);
+
+  entry->next = eht->dynlocal;
+  eht->dynlocal = entry;
+  entry->input_bfd = input_bfd;
+  entry->input_indx = input_indx;
+  eht->dynsymcount++;
+
+  /* Whatever binding the symbol had before, it's now local.  */
+  entry->isym.st_info
+    = ELF_ST_INFO (STB_LOCAL, ELF_ST_TYPE (entry->isym.st_info));
+
+  /* The dynindx will be set at the end of size_dynamic_sections.  */
+
+  return 1;
+}
+
 /* Return the dynindex of a local dynamic symbol.  */
 
 long
Index: bfd/elflink.h
===================================================================
RCS file: /cvs/src/src/bfd/elflink.h,v
retrieving revision 1.178
diff -u -p -r1.178 elflink.h
--- bfd/elflink.h	23 Jul 2002 04:38:17 -0000	1.178
+++ bfd/elflink.h	25 Jul 2002 06:41:35 -0000
@@ -2448,93 +2448,6 @@ elf_add_dynamic_entry (info, tag, val)
 
   return true;
 }
-
-/* Record a new local dynamic symbol.  */
-
-boolean
-elf_link_record_local_dynamic_symbol (info, input_bfd, input_indx)
-     struct bfd_link_info *info;
-     bfd *input_bfd;
-     long input_indx;
-{
-  struct elf_link_local_dynamic_entry *entry;
-  struct elf_link_hash_table *eht;
-  struct elf_strtab_hash *dynstr;
-  Elf_External_Sym esym;
-  Elf_External_Sym_Shndx eshndx;
-  Elf_External_Sym_Shndx *shndx;
-  unsigned long dynstr_index;
-  char *name;
-  file_ptr pos;
-  bfd_size_type amt;
-
-  if (! is_elf_hash_table (info))
-    return false;
-
-  /* See if the entry exists already.  */
-  for (entry = elf_hash_table (info)->dynlocal; entry ; entry = entry->next)
-    if (entry->input_bfd == input_bfd && entry->input_indx == input_indx)
-      return true;
-
-  entry = (struct elf_link_local_dynamic_entry *)
-    bfd_alloc (input_bfd, (bfd_size_type) sizeof (*entry));
-  if (entry == NULL)
-    return false;
-
-  /* Go find the symbol, so that we can find it's name.  */
-  amt = sizeof (Elf_External_Sym);
-  pos = elf_tdata (input_bfd)->symtab_hdr.sh_offset + input_indx * amt;
-  if (bfd_seek (input_bfd, pos, SEEK_SET) != 0
-      || bfd_bread ((PTR) &esym, amt, input_bfd) != amt)
-    return false;
-  shndx = NULL;
-  if (elf_tdata (input_bfd)->symtab_shndx_hdr.sh_size != 0)
-    {
-      amt = sizeof (Elf_External_Sym_Shndx);
-      pos = elf_tdata (input_bfd)->symtab_shndx_hdr.sh_offset;
-      pos += input_indx * amt;
-      shndx = &eshndx;
-      if (bfd_seek (input_bfd, pos, SEEK_SET) != 0
-	  || bfd_bread ((PTR) shndx, amt, input_bfd) != amt)
-	return false;
-    }
-  elf_swap_symbol_in (input_bfd, (const PTR) &esym, (const PTR) shndx,
-		      &entry->isym);
-
-  name = (bfd_elf_string_from_elf_section
-	  (input_bfd, elf_tdata (input_bfd)->symtab_hdr.sh_link,
-	   entry->isym.st_name));
-
-  dynstr = elf_hash_table (info)->dynstr;
-  if (dynstr == NULL)
-    {
-      /* Create a strtab to hold the dynamic symbol names.  */
-      elf_hash_table (info)->dynstr = dynstr = _bfd_elf_strtab_init ();
-      if (dynstr == NULL)
-	return false;
-    }
-
-  dynstr_index = _bfd_elf_strtab_add (dynstr, name, false);
-  if (dynstr_index == (unsigned long) -1)
-    return false;
-  entry->isym.st_name = dynstr_index;
-
-  eht = elf_hash_table (info);
-
-  entry->next = eht->dynlocal;
-  eht->dynlocal = entry;
-  entry->input_bfd = input_bfd;
-  entry->input_indx = input_indx;
-  eht->dynsymcount++;
-
-  /* Whatever binding the symbol had before, it's now local.  */
-  entry->isym.st_info
-    = ELF_ST_INFO (STB_LOCAL, ELF_ST_TYPE (entry->isym.st_info));
-
-  /* The dynindx will be set at the end of size_dynamic_sections.  */
-
-  return true;
-}
 \f
 /* Read and swap the relocs from the section indicated by SHDR.  This
    may be either a REL or a RELA section.  The relocations are

Re: SIGSEGV in ld at elflink.h:5500

[John David Anglin]

> 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)

Re: SIGSEGV in ld at elflink.h:5500

[Alan Modra]

On Fri, Jul 26, 2002 at 01:37:23PM -0400, John David Anglin wrote:
> /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

This touches on the general issue of exactly how gnu ld should handle
weak symbols.  It's something I'd like to correct post 2.13, as I
believe the current behaviour is wrong.  Ulrich, HJ, do you know
whether there is a proposal to specify weak sym handling in the works
for the ELF gabi?

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: SIGSEGV in ld at elflink.h:5500

[John David Anglin]

> On Fri, Jul 26, 2002 at 01:37:23PM -0400, John David Anglin wrote:
> > /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
> 
> This touches on the general issue of exactly how gnu ld should handle
> weak symbols.  It's something I'd like to correct post 2.13, as I
> believe the current behaviour is wrong.  Ulrich, HJ, do you know
> whether there is a proposal to specify weak sym handling in the works
> for the ELF gabi?

After I wrote, I found that removing "-E' from the link spec in pa64-hpux.h
allowed a complete build although there are a still huge number of testsuite
failures still related to this issue.

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

Re: SIGSEGV in ld at elflink.h:5500

[H. J. Lu]

On Sat, Jul 27, 2002 at 09:37:59AM +0930, Alan Modra wrote:
> On Fri, Jul 26, 2002 at 01:37:23PM -0400, John David Anglin wrote:
> > /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
> 
> This touches on the general issue of exactly how gnu ld should handle
> weak symbols.  It's something I'd like to correct post 2.13, as I
> believe the current behaviour is wrong.  Ulrich, HJ, do you know
> whether there is a proposal to specify weak sym handling in the works
> for the ELF gabi?

Check out ld/testsuite/ld-elfweak/elfweak.exp. There are 12 expected
failures. I can work on a patch. But we have to fix glibc first:

http://sources.redhat.com/ml/libc-alpha/2001-09/msg00109.html

Otherwise, Linux may be broken. I don't want to spend my time before
glibc is changed.



H.J.

Raise the test bar for hppa64-hpux and hppa-linux

[John David Anglin]

> Check out ld/testsuite/ld-elfweak/elfweak.exp. There are 12 expected
> failures. I can work on a patch. But we have to fix glibc first:

We aren't running many elf tests under hppa64-hpux and hppa-linux.  The
enclosed patch enables running these tests and fixes the tests in ld-discard
for hppa.

There are still many fails to resolve in running these tests.  For
example, we use crtend.o in tests with shared links.  Under hppa-linux,
this file is not compiled with "-fPIC".  I can see in the gcc source
some evidence that this file is compiled with "-fPIC" on some systems.
However, we now have crtbeginS.o for shared links.  Don't see any
support for this in configure.host or in any linker scripts.

Under hppa-linux, there are a bunch of fails like:

/home/dave/binutils-2.12.90/objdir/ld/ld-new  -o tmpdir/shnp.so -shared  tmpdir/
sh1np.o tmpdir/sh2np.o
/home/dave/binutils-2.12.90/objdir/ld/ld-new: tmpdir/sh1np.o: relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC
tmpdir/sh1np.o: could not read symbols: Bad value
FAIL: shared (non PIC)

Should I XFAIL these as I think "shared (non PIC)" is a not possible on pa.

I also see a bunch a number fails similar to:

diff tmpdir/shmpp.out /home/dave/binutils-2.12.90/src/ld/testsuite/ld-shared/sha
red.dat
12,15c12,15
< shlib_checkfunptr1 (shlib_shlibvar1) == 0
< shlib_checkfunptr2 (main_called) == 0
< shlib_getfunptr1 () != shlib_shlibvar1
< shlib_getfunptr2 () != main_called
---
> shlib_checkfunptr1 (shlib_shlibvar1) == 1
> shlib_checkfunptr2 (main_called) == 1
> shlib_getfunptr1 () == shlib_shlibvar1
> shlib_getfunptr2 () == main_called
child process exited abnormally
FAIL: shared (PIC main)

Please install if ok.

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

2002-07-28  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* ld-discard/discard.exp, ld-scripts/phdrs.exp, ld-scripts/phdrs2.exp,
	ld-selective/sel-dump.exp: Test hppa*64*-*-hpux* target.
	* ld-elfvers/vers.exp, ld-elfvsb/elfvsb.exp, ld-elfweak/elfweak.exp,
	ld-linkonce/linkonce.exp, ld-shared/shared.exp,
	ld-undefined/weak-undef.exp:  Test hppa*64*-*-hpux* and hppa*-*-linux*
	targets.
	* ld-discard/exit.s, ld-discard/extern.s, ld-discard/start.s,
	ld-discard/static.s: Add whitespace before assembler directives.

Index: ld-discard/discard.exp
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-discard/discard.exp,v
retrieving revision 1.1
diff -u -3 -p -r1.1 discard.exp
--- ld-discard/discard.exp	10 Nov 2001 01:17:57 -0000	1.1
+++ ld-discard/discard.exp	28 Jul 2002 18:53:16 -0000
@@ -22,7 +22,10 @@
 # Test for ELF here, so we don't have to qualify on ELF specifically
 # in every .d-file.
 
-if { ![istarget *-*-linux*] && ![istarget *-*-gnu] && ![istarget *-*-elf] } {
+if { ![istarget *-*-linux*] \
+     && ![istarget *-*-gnu] \
+     && ![istarget hppa*64*-*-hpux*] \
+     && ![istarget *-*-elf] } {
     return
 }
 
Index: ld-discard/exit.s
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-discard/exit.s,v
retrieving revision 1.1
diff -u -3 -p -r1.1 exit.s
--- ld-discard/exit.s	10 Nov 2001 01:17:57 -0000	1.1
+++ ld-discard/exit.s	28 Jul 2002 18:53:16 -0000
@@ -1,6 +1,6 @@
-.globl data
+	.globl data
 	.section	.data.exit,"aw"
 data:
-.globl text
+	.globl text
 	.section	.text.exit,"aw"
 text:
Index: ld-discard/extern.s
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-discard/extern.s,v
retrieving revision 1.1
diff -u -3 -p -r1.1 extern.s
--- ld-discard/extern.s	10 Nov 2001 01:17:57 -0000	1.1
+++ ld-discard/extern.s	28 Jul 2002 18:53:16 -0000
@@ -1,11 +1,11 @@
-.globl data
+	.globl data
 	.section	.data.exit,"aw"
 data:
-.globl text
+	.globl text
 	.section	.text.exit,"aw"
 text:
-.text
-.globl _start
+	.text
+	.globl _start
 _start:
 	.long	data
 	.section	.debug_info
Index: ld-discard/start.s
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-discard/start.s,v
retrieving revision 1.1
diff -u -3 -p -r1.1 start.s
--- ld-discard/start.s	10 Nov 2001 01:17:58 -0000	1.1
+++ ld-discard/start.s	28 Jul 2002 18:53:16 -0000
@@ -1,5 +1,5 @@
-.text
-.globl _start
+	.text
+	.globl _start
 _start:
 	.long	data
 	.section	.debug_info
Index: ld-discard/static.s
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-discard/static.s,v
retrieving revision 1.1
diff -u -3 -p -r1.1 static.s
--- ld-discard/static.s	10 Nov 2001 01:17:58 -0000	1.1
+++ ld-discard/static.s	28 Jul 2002 18:53:16 -0000
@@ -2,8 +2,8 @@
 data:
 	.section	.text.exit,"aw"
 text:
-.text
-.globl _start
+	.text
+	.globl _start
 _start:
 	.long	data
 	.section	.debug_info
Index: ld-elfvers/vers.exp
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-elfvers/vers.exp,v
retrieving revision 1.15
diff -u -3 -p -r1.15 vers.exp
--- ld-elfvers/vers.exp	16 Jul 2002 00:15:57 -0000	1.15
+++ ld-elfvers/vers.exp	28 Jul 2002 18:53:16 -0000
@@ -25,7 +25,9 @@ if ![isnative] then {return}
 # This test can only be run on a couple of ELF platforms.
 # Square bracket expressions seem to confuse istarget.
 # This is similar to the test that is used in ld-shared, BTW.
-if { ![istarget i?86-*-sysv4*] \
+if { ![istarget hppa*64*-*-hpux*] \
+     && ![istarget hppa*-*-linux*] \
+     && ![istarget i?86-*-sysv4*] \
      && ![istarget i?86-*-unixware] \
      && ![istarget i?86-*-elf*] \
      && ![istarget i?86-*-linux*] \
Index: ld-elfvsb/elfvsb.exp
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-elfvsb/elfvsb.exp,v
retrieving revision 1.13
diff -u -3 -p -r1.13 elfvsb.exp
--- ld-elfvsb/elfvsb.exp	19 Apr 2002 19:28:01 -0000	1.13
+++ ld-elfvsb/elfvsb.exp	28 Jul 2002 18:53:16 -0000
@@ -26,7 +26,9 @@ if ![isnative] then {return}
 
 # This test can only be run on a couple of ELF platforms.
 # Square bracket expressions seem to confuse istarget.
-if { ![istarget i?86-*-linux*] \
+if { ![istarget hppa*64*-*-hpux*] \
+     && ![istarget hppa*-*-linux*] \
+     && ![istarget i?86-*-linux*] \
      && ![istarget ia64-*-linux*] \
      && ![istarget m68k-*-linux*] \
      && ![istarget mips*-*-linux*] \
Index: ld-elfweak/elfweak.exp
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-elfweak/elfweak.exp,v
retrieving revision 1.3
diff -u -3 -p -r1.3 elfweak.exp
--- ld-elfweak/elfweak.exp	14 Sep 2001 23:43:17 -0000	1.3
+++ ld-elfweak/elfweak.exp	28 Jul 2002 18:53:16 -0000
@@ -25,7 +25,9 @@ if ![isnative] then {return}
 # This test can only be run on a couple of ELF platforms.
 # Square bracket expressions seem to confuse istarget.
 # This is similar to the test that is used in ld-shared, BTW.
-if { ![istarget i?86-*-sysv4*] \
+if { ![istarget hppa*64*-*-hpux*] \
+     && ![istarget hppa*-*-linux*] \
+     && ![istarget i?86-*-sysv4*] \
      && ![istarget i?86-*-unixware] \
      && ![istarget i?86-*-elf*] \
      && ![istarget i?86-*-linux*] \
Index: ld-linkonce/linkonce.exp
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-linkonce/linkonce.exp,v
retrieving revision 1.1
diff -u -3 -p -r1.1 linkonce.exp
--- ld-linkonce/linkonce.exp	29 Sep 2001 13:01:16 -0000	1.1
+++ ld-linkonce/linkonce.exp	28 Jul 2002 18:53:16 -0000
@@ -21,7 +21,10 @@
 # Test for ELF here (or really, .gnu.linkonce functionality), so we don't
 # have to qualify on ELF specifically in every .d-file.
 
-if { ![istarget *-*-linux*] && ![istarget *-*-gnu] && ![istarget *-*-elf] } {
+if { ![istarget *-*-linux*] \
+     && ![istarget *-*-gnu] \
+     && ![istarget hppa*64*-*-hpux*] \
+     && ![istarget *-*-elf] } {
     return
 }
 
Index: ld-scripts/phdrs.exp
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-scripts/phdrs.exp,v
retrieving revision 1.9
diff -u -3 -p -r1.9 phdrs.exp
--- ld-scripts/phdrs.exp	27 Aug 2001 10:49:55 -0000	1.9
+++ ld-scripts/phdrs.exp	28 Jul 2002 18:53:16 -0000
@@ -22,6 +22,7 @@ if { ![istarget *-*-sysv4*] \
      && ![istarget *-*-unixware*] \
      && ![istarget *-*-elf*] \
      && ![istarget *-*-eabi*] \
+     && ![istarget hppa*64*-*-hpux*] \
      && ![istarget *-*-linux*] \
      && ![istarget *-*-irix5*] \
      && ![istarget *-*-irix6*] \
Index: ld-scripts/phdrs2.exp
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-scripts/phdrs2.exp,v
retrieving revision 1.1
diff -u -3 -p -r1.1 phdrs2.exp
--- ld-scripts/phdrs2.exp	6 Jun 2002 10:03:38 -0000	1.1
+++ ld-scripts/phdrs2.exp	28 Jul 2002 18:53:16 -0000
@@ -19,6 +19,7 @@ if {    ![istarget *-*-sysv4*] \
      && ![istarget *-*-unixware*] \
      && ![istarget *-*-elf*] \
      && ![istarget *-*-eabi*] \
+     && ![istarget hppa*64*-*-hpux*] \
      && ![istarget *-*-linux*] \
      && ![istarget *-*-irix5*] \
      && ![istarget *-*-irix6*] \
Index: ld-selective/sel-dump.exp
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-selective/sel-dump.exp,v
retrieving revision 1.1
diff -u -3 -p -r1.1 sel-dump.exp
--- ld-selective/sel-dump.exp	5 Feb 2002 06:45:15 -0000	1.1
+++ ld-selective/sel-dump.exp	28 Jul 2002 18:53:16 -0000
@@ -20,6 +20,7 @@
 
 if { ![istarget *-*-linux*]
      && ![istarget *-*-gnu]
+     && ![istarget hppa*64*-*-hpux*]
      && ![istarget *-*-elf] } {
     return
 }
Index: ld-shared/shared.exp
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-shared/shared.exp,v
retrieving revision 1.12
diff -u -3 -p -r1.12 shared.exp
--- ld-shared/shared.exp	19 Apr 2002 19:28:06 -0000	1.12
+++ ld-shared/shared.exp	28 Jul 2002 18:53:17 -0000
@@ -28,7 +28,9 @@ if ![isnative] then {return}
 
 # This test can only be run on a couple of ELF platforms.
 # Square bracket expressions seem to confuse istarget.
-if { ![istarget i?86-*-sysv4*] \
+if { ![istarget hppa*64*-*-hpux*] \
+     && ![istarget hppa*-*-linux*] \
+     && ![istarget i?86-*-sysv4*] \
      && ![istarget i?86-*-unixware] \
      && ![istarget i?86-*-elf*] \
      && ![istarget i?86-*-linux*] \
Index: ld-undefined/weak-undef.exp
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-undefined/weak-undef.exp,v
retrieving revision 1.2
diff -u -3 -p -r1.2 weak-undef.exp
--- ld-undefined/weak-undef.exp	13 Mar 2001 06:14:29 -0000	1.2
+++ ld-undefined/weak-undef.exp	28 Jul 2002 18:53:17 -0000
@@ -25,6 +25,7 @@ if { ![istarget *-*-sysv4*] \
      && ![istarget *-*-unixware*] \
      && ![istarget *-*-elf*] \
      && ![istarget *-*-eabi*] \
+     && ![istarget hppa*64*-*-hpux*] \
      && ![istarget *-*-linux*] \
      && ![istarget *-*-irix5*] \
      && ![istarget *-*-irix6*] \

Re: Raise the test bar for hppa64-hpux and hppa-linux

[Alan Modra]

On Sun, Jul 28, 2002 at 07:04:13PM -0400, John David Anglin wrote:
> FAIL: shared (non PIC)
> 
> Should I XFAIL these as I think "shared (non PIC)" is a not possible on pa.

Yes please.

> < shlib_checkfunptr1 (shlib_shlibvar1) == 0
> < shlib_checkfunptr2 (main_called) == 0
> < shlib_getfunptr1 () != shlib_shlibvar1
> < shlib_getfunptr2 () != main_called
> ---
> > shlib_checkfunptr1 (shlib_shlibvar1) == 1
> > shlib_checkfunptr2 (main_called) == 1
> > shlib_getfunptr1 () == shlib_shlibvar1
> > shlib_getfunptr2 () == main_called
> child process exited abnormally
> FAIL: shared (PIC main)

I'd guess this one is a failure that needs fixing.  Probably due to
plabels.

> 	* ld-discard/discard.exp, ld-scripts/phdrs.exp, ld-scripts/phdrs2.exp,
> 	ld-selective/sel-dump.exp: Test hppa*64*-*-hpux* target.
> 	* ld-elfvers/vers.exp, ld-elfvsb/elfvsb.exp, ld-elfweak/elfweak.exp,
> 	ld-linkonce/linkonce.exp, ld-shared/shared.exp,
> 	ld-undefined/weak-undef.exp:  Test hppa*64*-*-hpux* and hppa*-*-linux*
> 	targets.
> 	* ld-discard/exit.s, ld-discard/extern.s, ld-discard/start.s,
> 	ld-discard/static.s: Add whitespace before assembler directives.

Installed.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: SIGSEGV in ld at elflink.h:5500

[John David Anglin]

> > 2002-07-10  Alan Modra  <amodra@bigpond.net.au>
> > 
> > 	* merge.c (_bfd_merge_section): Remove redundant output_section check.
> > 	Formatting.
> > 	(_bfd_merge_sections): Don't set SEC_EXCLUDE on unused sections.
> 
> bash-2.05a$ ./ld --version
> GNU ld version 2.12.90 20020716
> 
> As shown in the original gdb output, the output section is *ABS* which
> doesn't seem resonable for the symbol which is a weak function.  I

Looking at the history of the above, I see that the bug being fixed
had sym_sec->output_section set to bfd_abs_section.  The code in this
case was also being compiled with "-ffunction-sections" and we seem to
have the same problem, but on hppa64.

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

Re: SIGSEGV in ld at elflink.h:5500

[Alan Modra]

On Tue, Jul 16, 2002 at 08:34:40PM -0400, John David Anglin wrote:
> Looking at the history of the above, I see that the bug being fixed
> had sym_sec->output_section set to bfd_abs_section.  The code in this
> case was also being compiled with "-ffunction-sections" and we seem to
> have the same problem, but on hppa64.

Looking at your original email again.. :)  I see that what's happening
is that you're trying to output a dynamic symbol from a removed
linkonce section.  You need to find why ld is trying to do that, or in
fact why ld is outputting dynamic symbols for debugging sections.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: SIGSEGV in ld at elflink.h:5500

[John David Anglin]

> On Tue, Jul 16, 2002 at 08:34:40PM -0400, John David Anglin wrote:
> > Looking at the history of the above, I see that the bug being fixed
> > had sym_sec->output_section set to bfd_abs_section.  The code in this
> > case was also being compiled with "-ffunction-sections" and we seem to
> > have the same problem, but on hppa64.
> 
> Looking at your original email again.. :)  I see that what's happening
> is that you're trying to output a dynamic symbol from a removed
> linkonce section.  You need to find why ld is trying to do that, or in
> fact why ld is outputting dynamic symbols for debugging sections.

This could be the definition for ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX:

/* Handle special EH pointer encodings.  Absolute, pc-relative, and
   indirect are handled automatically.  Since pc-relative encoding is
   not possible on the PA and we don't have the infrastructure for
   data relative encoding, we use aligned plabels for global function
   pointers.  */
#define ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX(FILE, ENCODING, SIZE, ADDR, DONE) \
  do {                                                                  \
    if (((ENCODING) & 0x0F) == DW_EH_PE_aligned)                        \
      {                                                                 \
	fputs (integer_asm_op (SIZE, FALSE), FILE);                     \
	fputs ("P%", FILE);                                             \
	assemble_name (FILE, XSTR (ADDR, 0));                           \
	goto DONE;                                                      \
      }                                                                 \
    } while (0)

However, I didn't think that this is the problem since this still appears
to work under hppa-linux.  As far as I can tell, the only uses of the
above is to obtain the address of the personality function.  This also
occurs in a section which is loaded.

From the debugging I did, the symbols appear to be symbols for
weak functions.

I have confirmed that the problem is somehow related to the generation
of dwarf2 eh information.

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

Re: SIGSEGV in ld at elflink.h:5500

[Alan Modra]

On Tue, Jul 16, 2002 at 10:30:57PM -0400, John David Anglin wrote:
> I have confirmed that the problem is somehow related to the generation
> of dwarf2 eh information.

Yes, I suspect you're emitting dynamic relocs in debug sections.
If so, that needs to be stopped.  It's pointless because ld.so
won't relocate debug sections for you, and causes exactly the sort
of problems you're seeing.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: SIGSEGV in ld at elflink.h:5500

[John David Anglin]

> Looking at your original email again.. :)  I see that what's happening
> is that you're trying to output a dynamic symbol from a removed
> linkonce section.  You need to find why ld is trying to do that, or in
> fact why ld is outputting dynamic symbols for debugging sections.

Comparing the object files for string-inst.o with and without eh
frame info, the main difference in section information appears to
be that the file with eh frame info has a .debug_frame section
that the other doesn't have.  It has relocations like

RELOCATION RECORDS FOR [.debug_frame]:
OFFSET           TYPE              VALUE
0000000000000014 R_PARISC_SECREL32  .debug_frame
0000000000000018 R_PARISC_DIR64    .gnu.linkonce.t._ZNKSs7_M_dataEv
000000000000003c R_PARISC_SECREL32  .debug_frame
0000000000000040 R_PARISC_DIR64    .gnu.linkonce.t._ZNSs7_M_dataEPc
...

The hppa-linux 32-bit relocations are

RELOCATION RECORDS FOR [.debug_frame]:
OFFSET   TYPE              VALUE
00000014 R_PARISC_DIR32    .debug_frame
00000018 R_PARISC_DIR32    .gnu.linkonce.t._ZNKSs7_M_dataEv
00000024 R_PARISC_DIR32    .debug_frame
00000028 R_PARISC_DIR32    .gnu.linkonce.t._ZNSs7_M_dataEPc
...

I would guess that's the R_PARISC_DIR64 relocs that are the problem
but I am puzzled why the R_PARISC_DIR32 don't cause a similar problem.

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

Re: SIGSEGV in ld at elflink.h:5500

[Alan Modra]

On Wed, Jul 17, 2002 at 12:39:24AM -0400, John David Anglin wrote:
> but I am puzzled why the R_PARISC_DIR32 don't cause a similar problem.

Because elf32_hppa_check_relocs has this code

      if (need_entry & NEED_DYNREL)
	{
.
.
	  if (...
	       && (sec->flags & SEC_ALLOC) != 0

and similarly elsewhere.  elf32-hppa doesn't emit dynamic relocs for
debugging sections.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: SIGSEGV in ld at elflink.h:5500

[John David Anglin]

> On Wed, Jul 17, 2002 at 12:39:24AM -0400, John David Anglin wrote:
> > but I am puzzled why the R_PARISC_DIR32 don't cause a similar problem.
> 
> Because elf32_hppa_check_relocs has this code
> 
>       if (need_entry & NEED_DYNREL)
> 	{
> .
> .
> 	  if (...
> 	       && (sec->flags & SEC_ALLOC) != 0
> 
> and similarly elsewhere.  elf32-hppa doesn't emit dynamic relocs for
> debugging sections.

Hmmm, there seems to be a similar check in elf64-hppa.c

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

Re: SIGSEGV in ld at elflink.h:5500

[John David Anglin]

> On Wed, Jul 17, 2002 at 12:39:24AM -0400, John David Anglin wrote:
> > but I am puzzled why the R_PARISC_DIR32 don't cause a similar problem.
> 
> Because elf32_hppa_check_relocs has this code
> 
>       if (need_entry & NEED_DYNREL)
> 	{
> .
> .
> 	  if (...
> 	       && (sec->flags & SEC_ALLOC) != 0
> 
> and similarly elsewhere.  elf32-hppa doesn't emit dynamic relocs for
> debugging sections.

I don't think this is the problem.  As far as I can tell, we are
not emitting dynamic relocs for the debugging sections.

If you look back at the original report, you will see that the
".gnu.linkonce.t._ZTv0_n24_NSdD1Ev" section has its output_section
set to the bfd_abs_section.  It has SEC_ALLOC set in its flags
and SEC_EXCLUDE is not set.  It has a nonzero size.  Thus, the
only apparent reason that the output_section for this section
is set to the bfd_abs_section is that there are multiple copies
of this weak function/section.  Looking at the .o source files,
there appear to be four input objects containing this weak
function.

There are a couple of possibilities for the symbol reference
that causes the problem.  I know that the reloc is local,
from the .data section, from io-inst.o.  The SEC_ALLOC is
set in the flags of the .data section when the symbol is put
onto the dynlocal list.

We have the following assembly code for for _ZTv0_n24_NSdD1Ev in io-inst.s:

        .IMPORT _ZTv0_n24_NSdD1Ev,ENTRY
	.section        .gnu.linkonce.t._ZTv0_n24_NSdD1Ev,"ax",@progbits
	.align 8
	.weak   _ZTv0_n24_NSdD1Ev
	.EXPORT _ZTv0_n24_NSdD1Ev,ENTRY
L$FB1521
	.loc 40 64 0
_ZTv0_n24_NSdD1Ev
	.PROC
	.CALLINFO FRAME=128,CALLS,SAVE_RP,ENTRY_GR=3
	.ENTRY
	std %r2,-16(%r30)
L$CFI0122
	...

The symbol that causes the problem comes from io-inst.o.  io-inst.o
is the owner of the ".gnu.linkonce.t._ZTv0_n24_NSdD1Ev" section that
causes the seg fault.  The most likely symbol is a reference to
L$FB1521 in the .data section:

L$SFDE0073
        .word   L$EFDE0073-L$ASFDE0073
L$ASFDE0073
	.word   L$ASFDE0073-L$frame0001
	.dword  L$FB1521
	.dword  L$FE1521-L$FB1521
	...

This is code is not present without eh information, so we have the
link with enabling eh frame information.  The above is also consistent
with the DIR64 reloc.

So, what do we do?  We have have a reference in the data section
to a local label in a function that has been deleted.  On hppa-linux,
the above data is in .eh_frame.  Is it somehow special?

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

Re: SIGSEGV in ld at elflink.h:5500

[Alan Modra]

On Wed, Jul 17, 2002 at 11:20:02PM -0400, John David Anglin wrote:
> The symbol that causes the problem comes from io-inst.o.  io-inst.o
> is the owner of the ".gnu.linkonce.t._ZTv0_n24_NSdD1Ev" section that
> causes the seg fault.  The most likely symbol is a reference to
> L$FB1521 in the .data section:
> 
> L$SFDE0073
>         .word   L$EFDE0073-L$ASFDE0073
> L$ASFDE0073
> 	.word   L$ASFDE0073-L$frame0001
> 	.dword  L$FB1521
> 	.dword  L$FE1521-L$FB1521
> 	...
> 
> This is code is not present without eh information, so we have the
> link with enabling eh frame information.  The above is also consistent
> with the DIR64 reloc.
> 
> So, what do we do?  We have have a reference in the data section
> to a local label in a function that has been deleted.  On hppa-linux,
> the above data is in .eh_frame.  Is it somehow special?

OK, so it's likely a gcc bug.  You want the eh data in .eh_frame, as
.eh_frame is special.  See bfd/elflink.h:elf_bfd_discard_info.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: SIGSEGV in ld at elflink.h:5500

[John David Anglin]

> > So, what do we do?  We have have a reference in the data section
> > to a local label in a function that has been deleted.  On hppa-linux,
> > the above data is in .eh_frame.  Is it somehow special?
> 
> OK, so it's likely a gcc bug.  You want the eh data in .eh_frame, as
> .eh_frame is special.  See bfd/elflink.h:elf_bfd_discard_info.

I put the eh data into .eh_frame.  However, I still get a seg fault
at the same spot although the symbol and section have changed.  It
looks as if the code figured out that the reloc symbol was deleted
but still the fault.

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

Re: SIGSEGV in ld at elflink.h:5500

[Alan Modra]

On Thu, Jul 18, 2002 at 02:06:50AM -0400, John David Anglin wrote:
> > > So, what do we do?  We have have a reference in the data section
> > > to a local label in a function that has been deleted.  On hppa-linux,
> > > the above data is in .eh_frame.  Is it somehow special?
> > 
> > OK, so it's likely a gcc bug.  You want the eh data in .eh_frame, as
> > .eh_frame is special.  See bfd/elflink.h:elf_bfd_discard_info.
> 
> I put the eh data into .eh_frame.  However, I still get a seg fault
> at the same spot although the symbol and section have changed.  It
> looks as if the code figured out that the reloc symbol was deleted
> but still the fault.

Take a look at what's happening at elf64-hppa.c:1514 under gdb.
I suspect you have forced-local syms being added as local dynamic
syms.  Bad.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: SIGSEGV in ld at elflink.h:5500

[John David Anglin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=US-ASCII, Size: 2342 bytes --]

> On Thu, Jul 18, 2002 at 02:06:50AM -0400, John David Anglin wrote:
> > > > So, what do we do?  We have have a reference in the data section
> > > > to a local label in a function that has been deleted.  On hppa-linux,
> > > > the above data is in .eh_frame.  Is it somehow special?
> > > 
> > > OK, so it's likely a gcc bug.  You want the eh data in .eh_frame, as
> > > .eh_frame is special.  See bfd/elflink.h:elf_bfd_discard_info.
> > 
> > I put the eh data into .eh_frame.  However, I still get a seg fault
> > at the same spot although the symbol and section have changed.  It
> > looks as if the code figured out that the reloc symbol was deleted
> > but still the fault.
> 
> Take a look at what's happening at elf64-hppa.c:1514 under gdb.
> I suspect you have forced-local syms being added as local dynamic
> syms.  Bad.

I believe that only dynamic local syms are being added.  reloc_entries
are added to list by count_dyn_reloc.  This is only called when need_entry
has NEED_DYNREL, and sec->flags & SEC_ALLOC.  However, this is the path
by which the local dyn symbols are being added.  This must be something
wrong with the removal process for local dyn symbols.

I hacked elflink.h to skip discarded sections.  However, now ld
seg faults linking apps:

/xxx/gnu/gcc-3.2/objdir/gcc/libgcc.a(__main.o): In function `__do_global_dtors':
/xxx/gnu/gcc-3.2/objdir/gcc/../../gcc/gcc/libgcc2.c:1899: undefined reference to `__EH_FRAME_BEGIN__'

Program received signal SIGSEGV, Segmentation fault.
0x4000000000063164 in elf64_hppa_finalize_dlt (dyn_h=???, data=???)
    at ../../src/bfd/elf64-hppa.c:2271
2271                value += h->root.u.def.section->output_section->vma;
(gdb) p h->root
$3 = {root = {next = 0x8000000000154490,
    string = 0x800000000017e4be "__EH_FRAME_BEGIN__", hash = 60347007},
  type = bfd_link_hash_undefined, next = 0x80000000000eea30, u = {undef = {
      abfd = 0x8000000000091ad0}, def = {value = 9223372036855372496,
      section = 0x4000000000096420}, i = {link = 0x8000000000091ad0,
      warning = 0x4000000000096420 "òs\020!\n\223\n3òs\020c\n³\n36u"}, c = {
      size = 9223372036855372496, p = 0x4000000000096420}}}
	
Too many bugs.

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

SIGSEGV in ld at elflink.h:5500

[John David Anglin]

I started trying to get dwarf2 eh working on hppa64-hp-hpux.  I am
seeing a segmentation fault in gld linking the libstdc++-v3 shared
library.  This is the section data which causes the fault:

(gdb) p *s
$2 = {name = 0x8000000000240035 ".gnu.linkonce.t._ZTv0_n24_NSdD1Ev", id = 478, 
  index = 46, next = 0x8000000000246900, flags = 1049143, user_set_vma = 1, 
  reloc_done = 0, linker_mark = 0, linker_has_input = 0, gc_mark = 0, 
  segment_mark = 0, vma = 0, lma = 0, _cooked_size = 56, _raw_size = 56, 
  output_offset = 0, output_section = 0x8000000000005340, alignment_power = 3, 
  relocation = 0x0, orelocation = 0x0, reloc_count = 1, filepos = 127080, 
  rel_filepos = 204960, line_filepos = 0, userdata = 0x0, contents = 0x0, 
  lineno = 0x0, lineno_count = 0, entsize = 0, comdat = 0x0, 
  moving_line_filepos = 0, target_index = 0, used_by_bfd = 0x8000000000247698, 
  constructor_chain = 0x0, owner = 0x80000000000d7998, 
  symbol = 0x8000000000247638, symbol_ptr_ptr = 0x80000000002468c8, 
  link_order_head = 0x0, link_order_tail = 0x0}
(gdb) p *s->output_section
$3 = {name = 0x40000000000b0550 "*ABS*", id = 2, index = 0, next = 0x0, 
  flags = 0, user_set_vma = 0, reloc_done = 0, linker_mark = 0, 
  linker_has_input = 0, gc_mark = 1, segment_mark = 0, vma = 0, lma = 0, 
  _cooked_size = 0, _raw_size = 0, output_offset = 0, 
  output_section = 0x8000000000005340, alignment_power = 0, relocation = 0x0, 
  orelocation = 0x0, reloc_count = 0, filepos = 0, rel_filepos = 0, 
  line_filepos = 0, userdata = 0x0, contents = 0x0, lineno = 0x0, 
  lineno_count = 0, entsize = 0, comdat = 0x0, moving_line_filepos = 0, 
  target_index = 0, used_by_bfd = 0x0, constructor_chain = 0x0, owner = 0x0, 
  symbol = 0x80000000000050d8, symbol_ptr_ptr = 0x8000000000005338, 
  link_order_head = 0x0, link_order_tail = 0x0}

This is the code that faults:

                    sym.st_shndx =
		      elf_section_data (s->output_section)->this_idx;

The "elf_section_data" macro returns a null pointer.

Anybody got any ideas on what's causing this?

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

Re: SIGSEGV in ld at elflink.h:5500

[H. J. Lu]

On Tue, Jul 16, 2002 at 03:16:44PM -0400, John David Anglin wrote:
> I started trying to get dwarf2 eh working on hppa64-hp-hpux.  I am
> seeing a segmentation fault in gld linking the libstdc++-v3 shared
> library.  This is the section data which causes the fault:
> 
> (gdb) p *s
> $2 = {name = 0x8000000000240035 ".gnu.linkonce.t._ZTv0_n24_NSdD1Ev", id = 478, 
>   index = 46, next = 0x8000000000246900, flags = 1049143, user_set_vma = 1, 
>   reloc_done = 0, linker_mark = 0, linker_has_input = 0, gc_mark = 0, 
>   segment_mark = 0, vma = 0, lma = 0, _cooked_size = 56, _raw_size = 56, 
>   output_offset = 0, output_section = 0x8000000000005340, alignment_power = 3, 
>   relocation = 0x0, orelocation = 0x0, reloc_count = 1, filepos = 127080, 
>   rel_filepos = 204960, line_filepos = 0, userdata = 0x0, contents = 0x0, 
>   lineno = 0x0, lineno_count = 0, entsize = 0, comdat = 0x0, 
>   moving_line_filepos = 0, target_index = 0, used_by_bfd = 0x8000000000247698, 
>   constructor_chain = 0x0, owner = 0x80000000000d7998, 
>   symbol = 0x8000000000247638, symbol_ptr_ptr = 0x80000000002468c8, 
>   link_order_head = 0x0, link_order_tail = 0x0}
> (gdb) p *s->output_section
> $3 = {name = 0x40000000000b0550 "*ABS*", id = 2, index = 0, next = 0x0, 
>   flags = 0, user_set_vma = 0, reloc_done = 0, linker_mark = 0, 
>   linker_has_input = 0, gc_mark = 1, segment_mark = 0, vma = 0, lma = 0, 
>   _cooked_size = 0, _raw_size = 0, output_offset = 0, 
>   output_section = 0x8000000000005340, alignment_power = 0, relocation = 0x0, 
>   orelocation = 0x0, reloc_count = 0, filepos = 0, rel_filepos = 0, 
>   line_filepos = 0, userdata = 0x0, contents = 0x0, lineno = 0x0, 
>   lineno_count = 0, entsize = 0, comdat = 0x0, moving_line_filepos = 0, 
>   target_index = 0, used_by_bfd = 0x0, constructor_chain = 0x0, owner = 0x0, 
>   symbol = 0x80000000000050d8, symbol_ptr_ptr = 0x8000000000005338, 
>   link_order_head = 0x0, link_order_tail = 0x0}
> 
> This is the code that faults:
> 
>                     sym.st_shndx =
> 		      elf_section_data (s->output_section)->this_idx;
> 
> The "elf_section_data" macro returns a null pointer.
> 
> Anybody got any ideas on what's causing this?

Sounds similar to

http://sources.redhat.com/ml/binutils/2002-06/msg00047.html

I had to make

http://sources.redhat.com/ml/binutils/2002-06/msg00111.html



H.J.

Re: SIGSEGV in ld at elflink.h:5500

[Alan Modra]

On Tue, Jul 16, 2002 at 03:16:44PM -0400, John David Anglin wrote:
> This is the code that faults:
> 
>                     sym.st_shndx =
> 		      elf_section_data (s->output_section)->this_idx;

Are you using recent enough sources to have this patch?

2002-07-10  Alan Modra  <amodra@bigpond.net.au>

	* merge.c (_bfd_merge_section): Remove redundant output_section check.
	Formatting.
	(_bfd_merge_sections): Don't set SEC_EXCLUDE on unused sections.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: SIGSEGV in ld at elflink.h:5500

[John David Anglin]

> On Tue, Jul 16, 2002 at 03:16:44PM -0400, John David Anglin wrote:
> > This is the code that faults:
> > 
> >                     sym.st_shndx =
> > 		      elf_section_data (s->output_section)->this_idx;
> 
> Are you using recent enough sources to have this patch?
> 
> 2002-07-10  Alan Modra  <amodra@bigpond.net.au>
> 
> 	* merge.c (_bfd_merge_section): Remove redundant output_section check.
> 	Formatting.
> 	(_bfd_merge_sections): Don't set SEC_EXCLUDE on unused sections.

bash-2.05a$ ./ld --version
GNU ld version 2.12.90 20020716

As shown in the original gdb output, the output section is *ABS* which
doesn't seem resonable for the symbol which is a weak function.  I
thought this was related to changes to gcc to try to generate dwarf2
eh info on hppa64-hp-hpux* but maybe this is caused by the above or
some other recent binutils change.  I'll see.

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