Why does slurp_ia64_unwind_table complain unwind symbol type?

Why does slurp_ia64_unwind_table complain unwind symbol type?

[H. J. Lu]

slurp_ia64_unwind_table complains about unwind symbol type generated
by icc:

readelf: Warning: Skipping unexpected symbol type 2
readelf: Warning: Skipping unexpected symbol type 2
readelf: Warning: Skipping unexpected symbol type 1
readelf: Warning: Skipping unexpected symbol type 2
readelf: Warning: Skipping unexpected symbol type 2
readelf: Warning: Skipping unexpected symbol type 1

The code is

              if (ELF64_ST_TYPE (sym->st_info) != STT_SECTION)
                {
                  warn (_("Skipping unexpected symbol type %u\n"),
                        ELF64_ST_TYPE (sym->st_info));
                  continue;
                }

Why aren't STT_OBJECT and STT_FUNC allowed?


H.J.

Re: Why does slurp_ia64_unwind_table complain unwind symbol type?

[Alan Modra]

On Thu, Oct 21, 2004 at 09:17:04AM -0700, H. J. Lu wrote:
> readelf: Warning: Skipping unexpected symbol type 2

I see this on powerpc64-linux too.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Why does slurp_ia64_unwind_table complain unwind symbol type?

[David Mosberger]

It's been a while, but IIRC, the case you're seeing just wasn't
considered/tested/supported, because it didn't happen with GCC/gas,
hence the warning.

The symbol-table reading code assumes that if the unwind-table entries
are not absolute, they're relative to a section-start.  This appears
not to be true for icc v8.1 compiled programs.  For example:

 $ objdump --section .IA_64.unwind --reloc os-linux.o

 src/os-linux.o:     file format elf64-ia64-little

 RELOCATION RECORDS FOR [.IA_64.unwind]:
 OFFSET           TYPE              VALUE
 0000000000000000 SEGREL64LSB       _Uia64_get_elf_image
 0000000000000008 SEGREL64LSB       _Uia64_get_elf_image+0x0000000000000360
 0000000000000010 SEGREL64LSB       __udt__Uia64_get_elf_image
 0000000000000018 SEGREL64LSB       maps_next
 0000000000000020 SEGREL64LSB       maps_next+0x0000000000001900
 0000000000000028 SEGREL64LSB       __udt_maps_next
 0000000000000030 SEGREL64LSB       maps_init
 0000000000000038 SEGREL64LSB       maps_init+0x0000000000000370
 0000000000000040 SEGREL64LSB       __udt_maps_init

whereas the same GCC-compiled binary shows:

 $ objdump --section .IA_64.unwind --reloc src/os-linux.o

 src/os-linux.o:     file format elf64-ia64-little

 RELOCATION RECORDS FOR [.IA_64.unwind]:
 OFFSET           TYPE              VALUE
 0000000000000000 SEGREL64LSB       .text
 0000000000000008 SEGREL64LSB       .text+0x0000000000000560
 0000000000000010 SEGREL64LSB       .IA_64.unwind_info
 0000000000000018 SEGREL64LSB       .text+0x0000000000000560
 0000000000000020 SEGREL64LSB       .text+0x00000000000014d0
 0000000000000028 SEGREL64LSB       .IA_64.unwind_info+0x0000000000000028

IIRC, gas takes care of making values section-relative whenever
possible, so perhaps this is really a difference of gas vs. ias.

To support the icc/ias object files, I think we'd have to translate
the non-section symbols to a section/offset pair.  I _think_ that's as
easy as just adding the symbol's value.  The patch below seems to do
the trick for me.  If nobody sees any problem with it, please check it
in.

Thanks,

	--david

binutils/ChangeLog

2004-10-22  David Mosberger  <davidm@hpl.hp.com>

	* readelf.c (slurp_ia64_unwind_table): Support relocations against
	non-section symbols by adding in the symbol value.

Index: binutils/readelf.c
===================================================================
RCS file: /cvs/src/src/binutils/readelf.c,v
retrieving revision 1.257
diff -u -r1.257 readelf.c
--- binutils/readelf.c	12 Oct 2004 14:17:02 -0000	1.257
+++ binutils/readelf.c	22 Oct 2004 08:51:41 -0000
@@ -4409,25 +4409,11 @@
 	    {
 	      relname = elf_ia64_reloc_type (ELF32_R_TYPE (rp->r_info));
 	      sym = aux->symtab + ELF32_R_SYM (rp->r_info);
-
-	      if (ELF32_ST_TYPE (sym->st_info) != STT_SECTION)
-		{
-		  warn (_("Skipping unexpected symbol type %u\n"),
-			ELF32_ST_TYPE (sym->st_info));
-		  continue;
-		}
 	    }
 	  else
 	    {
 	      relname = elf_ia64_reloc_type (ELF64_R_TYPE (rp->r_info));
 	      sym = aux->symtab + ELF64_R_SYM (rp->r_info);
-
-	      if (ELF64_ST_TYPE (sym->st_info) != STT_SECTION)
-		{
-		  warn (_("Skipping unexpected symbol type %u\n"),
-			ELF64_ST_TYPE (sym->st_info));
-		  continue;
-		}
 	    }
 
 	  if (strncmp (relname, "R_IA64_SEGREL", 13) != 0)
@@ -4442,15 +4428,15 @@
 	    {
 	    case 0:
 	      aux->table[i].start.section = sym->st_shndx;
-	      aux->table[i].start.offset += rp->r_addend;
+	      aux->table[i].start.offset += rp->r_addend + sym->st_value;
 	      break;
 	    case 1:
 	      aux->table[i].end.section   = sym->st_shndx;
-	      aux->table[i].end.offset   += rp->r_addend;
+	      aux->table[i].end.offset   += rp->r_addend + sym->st_value;
 	      break;
 	    case 2:
 	      aux->table[i].info.section  = sym->st_shndx;
-	      aux->table[i].info.offset  += rp->r_addend;
+	      aux->table[i].info.offset  += rp->r_addend + sym->st_value;
 	      break;
 	    default:
 	      break;

Re: Why does slurp_ia64_unwind_table complain unwind symbol type?

[David Mosberger]

Speaking of binutils bugs: I still have the following patch in my
tree:

Index: bfd/elfxx-ia64.c
===================================================================
RCS file: /cvs/src/src/bfd/elfxx-ia64.c,v
retrieving revision 1.141
diff -u -r1.141 elfxx-ia64.c
--- bfd/elfxx-ia64.c	10 Oct 2004 13:58:05 -0000	1.141
+++ bfd/elfxx-ia64.c	22 Oct 2004 08:51:40 -0000
@@ -4339,10 +4339,14 @@
 	case R_IA64_SECREL64MSB:
 	case R_IA64_SECREL64LSB:
 	  /* Make output-section relative.  */
+#if 0
 	  if (value > input_section->output_section->vma)
 	    value -= input_section->output_section->vma;
 	  else
 	    value = 0;
+#else
+	  value -= input_section->output_section->vma;
+#endif
 	  r = elfNN_ia64_install_value (hit_addr, value, r_type);
 	  break;
 

I'm 99% certain this is correct and I have never seen any problems
with it (and it certainly fixes section-relative relocs which result
in negative values), so I think it should go in.

However, last time we discussed this, Rich Henderson thought there
might be an obscure issue that required the old code and suggested to
rebuild a Linux distro with the patch applied and watch if anything
breaks.  Unfortunately, I'm not well set up to do this myself
(meaning: I have no clue how I'd go about rebuilding all of, say,
Debian... ;-).

Can somebody help with testing this?

	--david

Re: Why does slurp_ia64_unwind_table complain unwind symbol type?

[H. J. Lu]

On Fri, Oct 22, 2004 at 01:56:50AM -0700, David Mosberger wrote:
> Speaking of binutils bugs: I still have the following patch in my
> tree:
> 
> Index: bfd/elfxx-ia64.c
> ===================================================================
> RCS file: /cvs/src/src/bfd/elfxx-ia64.c,v
> retrieving revision 1.141
> diff -u -r1.141 elfxx-ia64.c
> --- bfd/elfxx-ia64.c	10 Oct 2004 13:58:05 -0000	1.141
> +++ bfd/elfxx-ia64.c	22 Oct 2004 08:51:40 -0000
> @@ -4339,10 +4339,14 @@
>  	case R_IA64_SECREL64MSB:
>  	case R_IA64_SECREL64LSB:
>  	  /* Make output-section relative.  */
> +#if 0
>  	  if (value > input_section->output_section->vma)
>  	    value -= input_section->output_section->vma;
>  	  else
>  	    value = 0;
> +#else
> +	  value -= input_section->output_section->vma;
> +#endif
>  	  r = elfNN_ia64_install_value (hit_addr, value, r_type);
>  	  break;
>  
> 
> I'm 99% certain this is correct and I have never seen any problems
> with it (and it certainly fixes section-relative relocs which result
> in negative values), so I think it should go in.
> 
> However, last time we discussed this, Rich Henderson thought there
> might be an obscure issue that required the old code and suggested to
> rebuild a Linux distro with the patch applied and watch if anything
> breaks.  Unfortunately, I'm not well set up to do this myself
> (meaning: I have no clue how I'd go about rebuilding all of, say,
> Debian... ;-).
> 
> Can somebody help with testing this?

This is the original thread about the code in question:

http://sources.redhat.com/ml/binutils/2003-01/msg00399.html

It seems that the current binutils works fine with @secrel(). According
to Richard, those relocations are used for debug info. Testing this
change may not be easy. Do you have a testcase to show the problem
your change is tring to fix? If you do, please open a bug report at

http://www.sourceware.org/bugzilla/

I will try to fix it.

Thanks.


H.J.

Re: Why does slurp_ia64_unwind_table complain unwind symbol type?

[James E Wilson]

On Fri, 2004-10-22 at 01:53, David Mosberger wrote:
> 	* readelf.c (slurp_ia64_unwind_table): Support relocations against
> 	non-section symbols by adding in the symbol value.

Thanks.  HJ checked this in for you.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Why does slurp_ia64_unwind_table complain unwind symbol type?

[David Mosberger]

>>>>> On Mon, 25 Oct 2004 14:18:14 -0700, James E Wilson <wilson@specifixinc.com> said:

  James> On Fri, 2004-10-22 at 01:53, David Mosberger wrote:
  >> * readelf.c (slurp_ia64_unwind_table): Support relocations against
  >> non-section symbols by adding in the symbol value.

  James> Thanks.  HJ checked this in for you.

Thanks!

	--david

section-relative relocs on ia64 (was: Re: Why does slurp_ia64_unwind_table complain unwind symbol type?)

[David Mosberger]

>>>>> On Mon, 25 Oct 2004 09:16:06 -0700, "H. J. Lu" <hjl@lucon.org> said:

  HJ> This is the original thread about the code in question:

  HJ> http://sources.redhat.com/ml/binutils/2003-01/msg00399.html

Yup.

  HJ> It seems that the current binutils works fine with @secrel(). According
  HJ> to Richard, those relocations are used for debug info. Testing this
  HJ> change may not be easy. Do you have a testcase to show the problem
  HJ> your change is tring to fix? If you do, please open a bug report at

  HJ> http://www.sourceware.org/bugzilla/

  HJ> I will try to fix it.

OK, I'll submit a bug-report.  Turns out I misread the ia64 ABI a bit:
what GAS does at the moment is wrong, but for another reason than I
though.  I'll provide the details in the bug-report.

	--david

Re: section-relative relocs on ia64 (was: Re: Why does slurp_ia64_unwind_table complain unwind symbol type?)

[David Mosberger]

>>>>> On Tue, 26 Oct 2004 02:35:34 -0700, David Mosberger <davidm@linux.hpl.hp.com> said:

  David> I'll provide the details in the bug-report.

For completeness, here the reference to the bug-report:

  http://www.sourceware.org/bugzilla/show_bug.cgi?id=475

Thanks,

	--david

Re: section-relative relocs on ia64 (was: Re: Why does slurp_ia64_unwind_table complain unwind symbol type?)

[H. J. Lu]

On Tue, Oct 26, 2004 at 02:35:34AM -0700, David Mosberger wrote:
> 
> OK, I'll submit a bug-report.  Turns out I misread the ia64 ABI a bit:
> what GAS does at the moment is wrong, but for another reason than I
> though.  I'll provide the details in the bug-report.
> 

Here is a patch.


H.J.
----
2004-10-26  H.J. Lu  <hongjiu.lu@intel.com>

	PR 475
	* elfxx-ia64.c (elfNN_ia64_relocate_section): Correct
	R_IA64_SECREL32MSB, R_IA64_SECREL32LSB, R_IA64_SECREL64MSB
	and R_IA64_SECREL64LSB.

--- bfd/elfxx-ia64.c.secrel	2004-10-26 11:37:53.000000000 -0700
+++ bfd/elfxx-ia64.c	2004-10-26 14:10:05.480473581 -0700
@@ -4374,11 +4374,9 @@ elfNN_ia64_relocate_section (output_bfd,
 	case R_IA64_SECREL32LSB:
 	case R_IA64_SECREL64MSB:
 	case R_IA64_SECREL64LSB:
-	  /* Make output-section relative.  */
-	  if (value > input_section->output_section->vma)
-	    value -= input_section->output_section->vma;
-	  else
-	    value = 0;
+	  /* Make output-section relative to section where the symbol
+	     is defined. PR 475  */
+	  value -= sym_sec->output_section->vma;
 	  r = elfNN_ia64_install_value (hit_addr, value, r_type);
 	  break;
 

Re: section-relative relocs on ia64 (was: Re: Why does slurp_ia64_unwind_table complain unwind symbol type?)

[James E Wilson]

On Tue, 2004-10-26 at 14:13, H. J. Lu wrote:
> 	PR 475
> 	* elfxx-ia64.c (elfNN_ia64_relocate_section): Correct
> 	R_IA64_SECREL32MSB, R_IA64_SECREL32LSB, R_IA64_SECREL64MSB
> 	and R_IA64_SECREL64LSB.

Thanks.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: section-relative relocs on ia64 (was: Re: Why does slurp_ia64_unwind_table complain unwind symbol type?)

[David Mosberger]

>>>>> On Tue, 26 Oct 2004 14:13:51 -0700, "H. J. Lu" <hjl@lucon.org> said:

  HJ> Here is a patch.

Ah, that looks good (and easy).

  HJ> H.J.
  HJ> +	  /* Make output-section relative to section where the symbol
  HJ> +	     is defined. PR 475  */
  HJ> +	  value -= sym_sec->output_section->vma;

This is automatically guaranteed to never go negative, even for
corner-cases, such as weak symbols, right?

	--david

Re: section-relative relocs on ia64 (was: Re: Why does slurp_ia64_unwind_table complain unwind symbol type?)

[Alan Modra]

On Wed, Oct 27, 2004 at 03:03:38AM -0700, David Mosberger wrote:
> >>>>> On Tue, 26 Oct 2004 14:13:51 -0700, "H. J. Lu" <hjl@lucon.org> said:
> 
>   HJ> Here is a patch.
> 
> Ah, that looks good (and easy).
> 
>   HJ> H.J.
>   HJ> +	  /* Make output-section relative to section where the symbol
>   HJ> +	     is defined. PR 475  */
>   HJ> +	  value -= sym_sec->output_section->vma;
> 
> This is automatically guaranteed to never go negative, even for
> corner-cases, such as weak symbols, right?

Undefined weak might present a problem.  They'll have sym_sec == NULL.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: section-relative relocs on ia64 (was: Re: Why does slurp_ia64_unwind_table complain unwind symbol type?)

[H. J. Lu]

On Wed, Oct 27, 2004 at 10:23:09PM +0930, Alan Modra wrote:
> On Wed, Oct 27, 2004 at 03:03:38AM -0700, David Mosberger wrote:
> > >>>>> On Tue, 26 Oct 2004 14:13:51 -0700, "H. J. Lu" <hjl@lucon.org> said:
> > 
> >   HJ> Here is a patch.
> > 
> > Ah, that looks good (and easy).
> > 
> >   HJ> H.J.
> >   HJ> +	  /* Make output-section relative to section where the symbol
> >   HJ> +	     is defined. PR 475  */
> >   HJ> +	  value -= sym_sec->output_section->vma;
> > 
> > This is automatically guaranteed to never go negative, even for
> > corner-cases, such as weak symbols, right?
> 
> Undefined weak might present a problem.  They'll have sym_sec == NULL.
> 

David,

Does it look right?


H.J.
---
2004-10-27  H.J. Lu  <hongjiu.lu@intel.com>

	* elfxx-ia64.c (elfNN_ia64_relocate_section): Handle weak
	undefined symbols for R_IA64_SECREL32MSB, R_IA64_SECREL32LSB,
	R_IA64_SECREL64MSB and R_IA64_SECREL64LSB.

--- bfd/elfxx-ia64.c.weak	2004-10-26 16:05:02.000000000 -0700
+++ bfd/elfxx-ia64.c	2004-10-27 08:40:24.092936792 -0700
@@ -4376,7 +4376,8 @@ elfNN_ia64_relocate_section (output_bfd,
 	case R_IA64_SECREL64LSB:
 	  /* Make output-section relative to section where the symbol
 	     is defined. PR 475  */
-	  value -= sym_sec->output_section->vma;
+	  if (sym_sec)
+	    value -= sym_sec->output_section->vma;
 	  r = elfNN_ia64_install_value (hit_addr, value, r_type);
 	  break;
 

Re: section-relative relocs on ia64 (was: Re: Why does slurp_ia64_unwind_table complain unwind symbol type?)

[David Mosberger]

>>>>> On Wed, 27 Oct 2004 08:45:44 -0700, "H. J. Lu" <hjl@lucon.org> said:

  >> Undefined weak might present a problem.  They'll have sym_sec ==
  >> NULL.

  HJ> Does it look right?

  HJ> --- bfd/elfxx-ia64.c.weak	2004-10-26 16:05:02.000000000 -0700
  HJ> +++ bfd/elfxx-ia64.c	2004-10-27 08:40:24.092936792 -0700
  HJ> @@ -4376,7 +4376,8 @@ elfNN_ia64_relocate_section (output_bfd,
  HJ>  	case R_IA64_SECREL64LSB:
  HJ>  	  /* Make output-section relative to section where the symbol
  HJ>  	     is defined. PR 475  */
  HJ> -	  value -= sym_sec->output_section->vma;
  HJ> +	  if (sym_sec)
  HJ> +	    value -= sym_sec->output_section->vma;
  HJ>  	  r = elfNN_ia64_install_value (hit_addr, value, r_type);
  HJ>  	  break;

If we want to be paranoid, perhaps this would be safer:

	  if (sym_sec && value > sym_sec->output_section->vma)
	    value -= sym_sec->output_section->vma;
	  else
	    value = 0;

That should guarantee that we have no regression vs. the old code
(assuming sym_sec->output_section is never NULL).

Note that with the (corrected) interpretation of @symsec(expr), it's
impossible to have a real value that is negative, so "truncating" it
to zero is not a problem.

	--david

Re: section-relative relocs on ia64 (was: Re: Why does slurp_ia64_unwind_table complain unwind symbol type?)

[H. J. Lu]

On Wed, Oct 27, 2004 at 09:09:07AM -0700, David Mosberger wrote:
> >>>>> On Wed, 27 Oct 2004 08:45:44 -0700, "H. J. Lu" <hjl@lucon.org> said:
> 
>   >> Undefined weak might present a problem.  They'll have sym_sec ==
>   >> NULL.
> 
>   HJ> Does it look right?
> 
>   HJ> --- bfd/elfxx-ia64.c.weak	2004-10-26 16:05:02.000000000 -0700
>   HJ> +++ bfd/elfxx-ia64.c	2004-10-27 08:40:24.092936792 -0700
>   HJ> @@ -4376,7 +4376,8 @@ elfNN_ia64_relocate_section (output_bfd,
>   HJ>  	case R_IA64_SECREL64LSB:
>   HJ>  	  /* Make output-section relative to section where the symbol
>   HJ>  	     is defined. PR 475  */
>   HJ> -	  value -= sym_sec->output_section->vma;
>   HJ> +	  if (sym_sec)
>   HJ> +	    value -= sym_sec->output_section->vma;
>   HJ>  	  r = elfNN_ia64_install_value (hit_addr, value, r_type);
>   HJ>  	  break;
> 
> If we want to be paranoid, perhaps this would be safer:
> 
> 	  if (sym_sec && value > sym_sec->output_section->vma)
> 	    value -= sym_sec->output_section->vma;
> 	  else
> 	    value = 0;

I checked. If sym_sec is NULL, value will be 0. Otherwise value is
always >= sym_sec->output_section->vma. So mine gets the same result
as yours.

> 
> That should guarantee that we have no regression vs. the old code
> (assuming sym_sec->output_section is never NULL).
> 
> Note that with the (corrected) interpretation of @symsec(expr), it's
> impossible to have a real value that is negative, so "truncating" it
> to zero is not a problem.


H.J.

Re: section-relative relocs on ia64 (was: Re: Why does slurp_ia64_unwind_table complain unwind symbol type?)

[David Mosberger]

>>>>> On Wed, 27 Oct 2004 09:18:27 -0700, "H. J. Lu" <hjl@lucon.org> said:

  H> I checked. If sym_sec is NULL, value will be 0. Otherwise value
  H> is always >= sym_sec->output_section->vma. So mine gets the same
  H> result as yours.

Looks good to me, then.

Thanks,

	--david