Re: binutils: "unexpected reloc type 0x17" on sparc

Re: binutils: "unexpected reloc type 0x17" on sparc

[H . J . Lu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1989 bytes --]

On Thu, Jun 28, 2001 at 11:19:44PM +0200, Tomasz K³oczko wrote:
> 
> Seems somewhere between binutils 2.11.90.0.8 and 2.11.90.0.19 was
> inroduced some king bug which causes generate by ld mangled binaries on
> sparc. I have few development enviroment. One thon them is on some sparc
> and on the same computer in chroot()ed enviroment I have other. In chroot
> I have binutils 2.11.90.0.19 and in main 2.11.90.0.8. In both I have the
> same compiler (gcc 2.95.3) and the same glibc (2.2.3) version (the same
> gcc and glibc binaries in both enviroments).
> 
> Few days ago I observe in chroot some binaries binaries fails on execution
> with "unexpected reloc type 0x17". As experiment in both enviroments I try
> find some diffrence and I found. For example I try rebuild glibc using
> newer binutils (2.11.90.0.19) fails on:
> 
> -D_LIBC_REENTRANT -include ../include/libc-symbols.h -D_RPC_THREAD_SAFE_
> -o rpcinfo.o gcc -nostdlib -nostartfiles -o rpcinfo
> -Wl,-dynamic-linker=/lib/ld-linux.so.2 ../csu/crt1.o ../csu/crti.o `gcc
> --print-file-name=crtbegin.o` rpcinfo.o
> -Wl,-rpath-link=..:../math:../elf:../dlfcn:../nss:../nis:../rt:../resolv:../crypt:../linuxthreads
> ../libc.so.6 ../libc_nonshared.a -lgcc `gcc --print-file-name=crtend.o`
> ../csu/crtn.o ../elf/ld-linux.so.2 --library-path
> ..:../math:../elf:../dlfcn:../nss:../nis:../rt:../resolv:../crypt:../linuxthreads
> ./rpcgen -Y `gcc -print-file-name=cpp | sed 's|/cpp$||'` -c
> rpcsvc/bootparam_prot.x -o xbootparam_prot.T
> ./rpcgen: error while loading shared libraries: ../libc.so.6: unexpected reloc type 0x17
> make[1]: *** [xbootparam_prot.stmp] Error 127
> make[1]: Leaving directory
> `/home/users/builder/rpm/BUILD/glibc-2.2.3/sunrpc'
> make: *** [sunrpc/others] Error 2
> 
> I cant find what is going on and IMHO new ld from binutils probably is
> buggy.

0x17 == R_SPARC_UA32. The new linker generates them. I think glibc has
to be fixed to deal with R_SPARC_UA32, R_SPARC_UA64 and R_SPARC_UA16.


H.J.

Re: binutils: "unexpected reloc type 0x17" on sparc

[David S. Miller]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

H . J . Lu writes:
 > On Thu, Jun 28, 2001 at 11:19:44PM +0200, Tomasz K³oczko wrote:
 > > I cant find what is going on and IMHO new ld from binutils probably is
 > > buggy.
 > 
 > 0x17 == R_SPARC_UA32. The new linker generates them. I think glibc has
 > to be fixed to deal with R_SPARC_UA32, R_SPARC_UA64 and R_SPARC_UA16.

I was under the impression that R_SPARC_UA{32,64,16} should never show
up as a dynamic reloc.

If this is OK, then this binutils change breaks every Sparc/Linux
system out there since no GLIBC version (even today in CVS) handles
these dynamic relocs.

Later,
David S. Miller
davem@redhat.com

Re: binutils: "unexpected reloc type 0x17" on sparc

[Richard Henderson]

On Thu, Jun 28, 2001 at 03:11:50PM -0700, David S. Miller wrote:
> I was under the impression that R_SPARC_UA{32,64,16} should never show
> up as a dynamic reloc.

Why wouldn't they show up in dynamic relocs?  There's no other point
for having them!  They are a speed optimization for the dynamic linker,
so that it needn't assume R_SPARC_32 may be unaligned.

> If this is OK, then this binutils change breaks every Sparc/Linux
> system out there since no GLIBC version (even today in CVS) handles
> these dynamic relocs.

Too bad, as this binutils change is required for things to work
on Solaris, which otherwise gets SIGBUS on the unaligned write.


r~

Re: binutils: "unexpected reloc type 0x17" on sparc

[David S. Miller]

Richard Henderson writes:
 > Why wouldn't they show up in dynamic relocs?  There's no other point
 > for having them!  They are a speed optimization for the dynamic linker,
 > so that it needn't assume R_SPARC_32 may be unaligned.

Ok then.

 > > If this is OK, then this binutils change breaks every Sparc/Linux
 > > system out there since no GLIBC version (even today in CVS) handles
 > > these dynamic relocs.
 > 
 > Too bad, as this binutils change is required for things to work
 > on Solaris, which otherwise gets SIGBUS on the unaligned write.

What I'm really trying to understand is why we've gotten away with not
having this for all this time. :-)

Is this being emitted for something new like stack unwind info or
dwarf2 debugging stuff?

Later,
David S. Miller
davem@redhat.com

Re: binutils: "unexpected reloc type 0x17" on sparc

[Ian Lance Taylor]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]

"David S. Miller" <davem@redhat.com> writes:

> H . J . Lu writes:
>  > On Thu, Jun 28, 2001 at 11:19:44PM +0200, Tomasz K³oczko wrote:
>  > > I cant find what is going on and IMHO new ld from binutils probably is
>  > > buggy.
>  > 
>  > 0x17 == R_SPARC_UA32. The new linker generates them. I think glibc has
>  > to be fixed to deal with R_SPARC_UA32, R_SPARC_UA64 and R_SPARC_UA16.
> 
> I was under the impression that R_SPARC_UA{32,64,16} should never show
> up as a dynamic reloc.

In my opinion, there should be no restrictions on which relocations
can appear as dynamic relocations.  Such restrictions serve no useful
purpose, and handicap the program linker.

That said, I don't know why the program linker would emit a
R_SPARC_UA32 dynamic relocation, except for some odd cases in
debugging sections.  They should only appear when .uaword is
explicitly used in the assembler source.

Actually, I now look at gcc/config/sparc/sol2.h, and I see that it
uses .uaword for ASM_LONG.  Hmmm.  I would assume that generates
R_SPARC_UA32 with the Solaris assembler and linker, and I assume the
Solaris dynamic linker is prepared to handle R_SPARC_UA32.  Perhaps
somebody could check that.  It's probably less efficient for gcc to do
that, since it means the dynamic linker has to be careful how it
handles the reloc.

Ian

Re: binutils: "unexpected reloc type 0x17" on sparc

[H . J . Lu]

On Thu, Jun 28, 2001 at 03:21:17PM -0700, David S. Miller wrote:
>  > 
>  > Too bad, as this binutils change is required for things to work
>  > on Solaris, which otherwise gets SIGBUS on the unaligned write.
> 
> What I'm really trying to understand is why we've gotten away with not
> having this for all this time. :-)

Does Linux sparc kernels have unaligned access support? We can fix
glibc and I put a word in my binutils release note.


H.J.

Re: binutils: "unexpected reloc type 0x17" on sparc

[Ian Lance Taylor]

Richard Henderson <rth@redhat.com> writes:

> On Thu, Jun 28, 2001 at 03:11:50PM -0700, David S. Miller wrote:
> > I was under the impression that R_SPARC_UA{32,64,16} should never show
> > up as a dynamic reloc.
> 
> Why wouldn't they show up in dynamic relocs?  There's no other point
> for having them!  They are a speed optimization for the dynamic linker,
> so that it needn't assume R_SPARC_32 may be unaligned.

Pedantically speaking, that is not the only reason.  They also permit
the program linker to run faster, because the relocation may be
assumed to be aligned within the section contents.  It so happens that
the GNU linker does not take advantage of that possible optimization.
I expect that the Solaris linker does.

Ian

Re: binutils: "unexpected reloc type 0x17" on sparc

[Ian Lance Taylor]

"David S. Miller" <davem@redhat.com> writes:

>  > > If this is OK, then this binutils change breaks every Sparc/Linux
>  > > system out there since no GLIBC version (even today in CVS) handles
>  > > these dynamic relocs.
>  > 
>  > Too bad, as this binutils change is required for things to work
>  > on Solaris, which otherwise gets SIGBUS on the unaligned write.
> 
> What I'm really trying to understand is why we've gotten away with not
> having this for all this time. :-)
> 
> Is this being emitted for something new like stack unwind info or
> dwarf2 debugging stuff?

The GNU assembler was recently (May 28) fixed to use R_SPARC_UA32 and
friends for .ualong and friends.  That was always correct--compare
with the Solaris assembler--but for a long time the GNU assembler
incorrectly used R_SPARC_32.

Ian

Re: binutils: "unexpected reloc type 0x17" on sparc

[David S. Miller]

H . J . Lu writes:
 > On Thu, Jun 28, 2001 at 03:21:17PM -0700, David S. Miller wrote:
 > >  > 
 > >  > Too bad, as this binutils change is required for things to work
 > >  > on Solaris, which otherwise gets SIGBUS on the unaligned write.
 > > 
 > > What I'm really trying to understand is why we've gotten away with not
 > > having this for all this time. :-)
 > 
 > Does Linux sparc kernels have unaligned access support? We can fix
 > glibc and I put a word in my binutils release note.

No it does not, userland should never make an unaligned access.

Later,
David S. Miller
davem@redhat.com

Re: binutils: "unexpected reloc type 0x17" on sparc

[David S. Miller]

Ian Lance Taylor writes:
 > "David S. Miller" <davem@redhat.com> writes:
 > > What I'm really trying to understand is why we've gotten away with not
 > > having this for all this time. :-)
 > > 
 > > Is this being emitted for something new like stack unwind info or
 > > dwarf2 debugging stuff?
 > 
 > The GNU assembler was recently (May 28) fixed to use R_SPARC_UA32 and
 > friends for .ualong and friends.  That was always correct--compare
 > with the Solaris assembler--but for a long time the GNU assembler
 > incorrectly used R_SPARC_32.

Ok, and you've shown that sol2.h in GCC uses these directives for
ASM_LONG.  But this isn't Linux.

Actually, it is even more confusing now, because things worked
perfectly fine under Linux previously as far as we know right?
It was emitting R_SPARC_32 and not R_SPARC_UA32.

I mean, I'll tool around in the gcc-3.0 and cvs binutils sources
to try and figure this out, but someone here can probably dig into
it more quickly than I at the moment.

Later,
David S. Miller
davem@redhat.com

Re: binutils: "unexpected reloc type 0x17" on sparc

[Richard Henderson]

On Thu, Jun 28, 2001 at 03:21:17PM -0700, David S. Miller wrote:
> What I'm really trying to understand is why we've gotten away with not
> having this for all this time. :-)
> 
> Is this being emitted for something new like stack unwind info or
> dwarf2 debugging stuff?

By accident, or undocumented carefulness, I'm not sure which.

In either case, we weren't using the dwarf2 frame augmentation
field properly.  Fixing that (as well as tweeking other bits
at the same time) meant that the pointer to the EH type info
is no longer aligned.



r~

Re: binutils: "unexpected reloc type 0x17" on sparc

[Ian Lance Taylor]

"David S. Miller" <davem@redhat.com> writes:

> Ian Lance Taylor writes:
>  > "David S. Miller" <davem@redhat.com> writes:
>  > > What I'm really trying to understand is why we've gotten away with not
>  > > having this for all this time. :-)
>  > > 
>  > > Is this being emitted for something new like stack unwind info or
>  > > dwarf2 debugging stuff?
>  > 
>  > The GNU assembler was recently (May 28) fixed to use R_SPARC_UA32 and
>  > friends for .ualong and friends.  That was always correct--compare
>  > with the Solaris assembler--but for a long time the GNU assembler
>  > incorrectly used R_SPARC_32.
> 
> Ok, and you've shown that sol2.h in GCC uses these directives for
> ASM_LONG.  But this isn't Linux.

Hmmm.  Yeah.

> Actually, it is even more confusing now, because things worked
> perfectly fine under Linux previously as far as we know right?
> It was emitting R_SPARC_32 and not R_SPARC_UA32.

That was going to happen no matter what gcc used, because until
recently the GNU assembler emitted R_SPARC_32 for both .word and
.uaword.

> I mean, I'll tool around in the gcc-3.0 and cvs binutils sources
> to try and figure this out, but someone here can probably dig into
> it more quickly than I at the moment.

A little grep shows that SPARC gcc will use .uaword for
UNALIGNED_INT_ASM_OP, but that is only used by DWARF.

Looking at the code in gas, it looks buggy to me.  It looks to me like
this:
    .uaword 0
    .word foo
will cause R_SPARC_UA32 for the latter when it shouldn't.  Does
anybody want to build a SPARC gas to test?

If that is in fact the case, the easy fix would be to define
md_flush_pending_output to clear sparc_no_align_cons.

Ian

Re: binutils: "unexpected reloc type 0x17" on sparc

[Jakub Jelinek]

On Thu, Jun 28, 2001 at 03:42:52PM -0700, David S. Miller wrote:
> Actually, it is even more confusing now, because things worked
> perfectly fine under Linux previously as far as we know right?
> It was emitting R_SPARC_32 and not R_SPARC_UA32.
> 
> I mean, I'll tool around in the gcc-3.0 and cvs binutils sources
> to try and figure this out, but someone here can probably dig into
> it more quickly than I at the moment.

That's why I asked for the library in question, so that it is clear whether
glibc's dl-machine.h needs to be changed or binutils fixed.

	Jakub

Re: binutils: "unexpected reloc type 0x17" on sparc

[Alan Modra]

On Fri, Jun 29, 2001 at 07:16:48AM +0200, Jakub Jelinek wrote:
> On Thu, Jun 28, 2001 at 03:42:52PM -0700, David S. Miller wrote:
> > Actually, it is even more confusing now, because things worked
> > perfectly fine under Linux previously as far as we know right?
> > It was emitting R_SPARC_32 and not R_SPARC_UA32.
> > 
> > I mean, I'll tool around in the gcc-3.0 and cvs binutils sources
> > to try and figure this out, but someone here can probably dig into
> > it more quickly than I at the moment.
> 
> That's why I asked for the library in question, so that it is clear whether
> glibc's dl-machine.h needs to be changed or binutils fixed.
> 

One thing you might like to consider doing is to massage the reloc type
depending on its offset, before calling bfd_elf32_swap_reloca_out
(elf32-sparc.c:1531).  That way, you'll only get the UA relocs when you
really need them.

-- 
Alan Modra

[PATCH] Re: binutils: "unexpected reloc type 0x17" on sparc

[Jakub Jelinek]

On Fri, Jun 29, 2001 at 03:05:10PM +0930, Alan Modra wrote:
> On Fri, Jun 29, 2001 at 07:16:48AM +0200, Jakub Jelinek wrote:
> > On Thu, Jun 28, 2001 at 03:42:52PM -0700, David S. Miller wrote:
> > > Actually, it is even more confusing now, because things worked
> > > perfectly fine under Linux previously as far as we know right?
> > > It was emitting R_SPARC_32 and not R_SPARC_UA32.
> > > 
> > > I mean, I'll tool around in the gcc-3.0 and cvs binutils sources
> > > to try and figure this out, but someone here can probably dig into
> > > it more quickly than I at the moment.
> > 
> > That's why I asked for the library in question, so that it is clear whether
> > glibc's dl-machine.h needs to be changed or binutils fixed.
> > 
> 
> One thing you might like to consider doing is to massage the reloc type
> depending on its offset, before calling bfd_elf32_swap_reloca_out
> (elf32-sparc.c:1531).  That way, you'll only get the UA relocs when you
> really need them.

That's what elf64-sparc.c is already doing, wonder why it was missing in
elf32-sparc.c.
Tomasz, does the following patch help?
While writing it, I've noticed someone added support for R_SPARC_UA64 into
elf32-sparc.c. That does not make sense to me in the light that sparc32 is
not supporting R_SPARC_64 either. Simply putting anything but assembly time
constant into .xword, .uaxword or .8byte is bad assembly on SPARC 32bit.
As far as glibc is concerned, if you show me a real-world DSO which really
needs R_SPARC_UA16 or R_SPARC_UA32, then I'll happily add those relocs to
sparc/sparc32/dl-machine.h, but the libstdc++ Artur mailed me had just
R_SPARC_UA32 with all r_offsets divisible by 4.

2001-06-29  Jakub Jelinek  <jakub@redhat.com>

	* elf32-sparc.c (_bfd_sparc_elf_howto_table): Remove support for
	R_SPARC_UA64.
	(elf32_sparc_check_relocs): Likewise.
	(elf32_sparc_relocate_section): Likewise.
	Optimize unaligned reloc usage.

--- bfd/elf32-sparc.c.jj	Fri Jun 29 11:58:58 2001
+++ bfd/elf32-sparc.c	Fri Jun 29 12:24:17 2001
@@ -120,7 +120,7 @@ reloc_howto_type _bfd_sparc_elf_howto_ta
   HOWTO(R_SPARC_NONE,      0,0, 0,false,0,complain_overflow_dont,    bfd_elf_generic_reloc,  "R_SPARC_NONE",    false,0,0x00000000,true),
   HOWTO(R_SPARC_NONE,      0,0, 0,false,0,complain_overflow_dont,    bfd_elf_generic_reloc,  "R_SPARC_NONE",    false,0,0x00000000,true),
   HOWTO(R_SPARC_NONE,      0,0, 0,false,0,complain_overflow_dont,    bfd_elf_generic_reloc,  "R_SPARC_NONE",    false,0,0x00000000,true),
-  HOWTO(R_SPARC_UA64,      0,4,64,false,0,complain_overflow_bitfield,bfd_elf_generic_reloc,  "R_SPARC_UA64",    false,0,(~ (bfd_vma)0), true),
+  HOWTO(R_SPARC_UA64,      0,0, 0,false,0,complain_overflow_dont,    sparc_elf_notsupported_reloc,  "R_SPARC_UA64",    false,0,0x00000000,true),
   HOWTO(R_SPARC_UA16,      0,1,16,false,0,complain_overflow_bitfield,bfd_elf_generic_reloc,  "R_SPARC_UA16",    false,0,0x0000ffff,true),
   HOWTO(R_SPARC_REV32,     0,2,32,false,0,complain_overflow_bitfield,bfd_elf_generic_reloc,  "R_SPARC_REV32",   false,0,0xffffffff,true),
 };
@@ -554,7 +554,6 @@ elf32_sparc_check_relocs (abfd, info, se
 	case R_SPARC_LO10:
 	case R_SPARC_UA16:
 	case R_SPARC_UA32:
-	case R_SPARC_UA64:
 	  if (h != NULL)
 	    h->elf_link_hash_flags |= ELF_LINK_NON_GOT_REF;
 
@@ -1223,7 +1222,6 @@ elf32_sparc_relocate_section (output_bfd
 			  || r_type == R_SPARC_LO10
 			  || r_type == R_SPARC_UA16
 			  || r_type == R_SPARC_UA32
-			  || r_type == R_SPARC_UA64
 			  || ((r_type == R_SPARC_PC10
 			       || r_type == R_SPARC_PC22)
 			      && strcmp (h->root.root.string,
@@ -1412,7 +1410,6 @@ elf32_sparc_relocate_section (output_bfd
 	case R_SPARC_LO10:
 	case R_SPARC_UA16:
 	case R_SPARC_UA32:
-	case R_SPARC_UA64:
 	  if (info->shared)
 	    {
 	      Elf_Internal_Rela outrel;
@@ -1463,6 +1460,24 @@ elf32_sparc_relocate_section (output_bfd
 	      outrel.r_offset += (input_section->output_section->vma
 				  + input_section->output_offset);
 
+	      /* Optimize unaligned reloc usage now that we know where
+		 it finally resides.  */
+	      switch (r_type)
+		{
+		case R_SPARC_16:
+		  if (outrel.r_offset & 1) r_type = R_SPARC_UA16;
+		  break;
+		case R_SPARC_UA16:
+		  if (!(outrel.r_offset & 1)) r_type = R_SPARC_16;
+		  break;
+		case R_SPARC_32:
+		  if (outrel.r_offset & 3) r_type = R_SPARC_UA32;
+		  break;
+		case R_SPARC_UA32:
+		  if (!(outrel.r_offset & 3)) r_type = R_SPARC_32;
+		  break;
+		}
+
 	      if (skip)
 		memset (&outrel, 0, sizeof outrel);
 	      /* h->dynindx may be -1 if the symbol was marked to
@@ -2024,7 +2039,7 @@ elf32_sparc_object_p (abfd)
     }
   else if (elf_elfheader (abfd)->e_flags & EF_SPARC_LEDATA)
     return bfd_default_set_arch_mach (abfd, bfd_arch_sparc,
-                                      bfd_mach_sparc_sparclite_le);
+				      bfd_mach_sparc_sparclite_le);
   else
     return bfd_default_set_arch_mach (abfd, bfd_arch_sparc, bfd_mach_sparc);
 }


	Jakub

Re: [PATCH] Re: binutils: "unexpected reloc type 0x17" on sparc

[Ian Lance Taylor]

Jakub Jelinek <jakub@redhat.com> writes:

> As far as glibc is concerned, if you show me a real-world DSO which really
> needs R_SPARC_UA16 or R_SPARC_UA32, then I'll happily add those relocs to
> sparc/sparc32/dl-machine.h, but the libstdc++ Artur mailed me had just
> R_SPARC_UA32 with all r_offsets divisible by 4.

Do it now.  Why wait until somebody has trouble?  It's probably easy
to create a C test case using attribute((__packed__)).

Ian

Re: [PATCH] Re: binutils: "unexpected reloc type 0x17" on sparc

[Ian Lance Taylor]

Jakub Jelinek <jakub@redhat.com> writes:

> @@ -1463,6 +1460,24 @@ elf32_sparc_relocate_section (output_bfd
>  	      outrel.r_offset += (input_section->output_section->vma
>  				  + input_section->output_offset);
>  
> +	      /* Optimize unaligned reloc usage now that we know where
> +		 it finally resides.  */
> +	      switch (r_type)
> +		{
> +		case R_SPARC_16:
> +		  if (outrel.r_offset & 1) r_type = R_SPARC_UA16;
> +		  break;
> +		case R_SPARC_UA16:
> +		  if (!(outrel.r_offset & 1)) r_type = R_SPARC_16;
> +		  break;
> +		case R_SPARC_32:
> +		  if (outrel.r_offset & 3) r_type = R_SPARC_UA32;
> +		  break;
> +		case R_SPARC_UA32:
> +		  if (!(outrel.r_offset & 3)) r_type = R_SPARC_32;
> +		  break;
> +		}
> +
>  	      if (skip)
>  		memset (&outrel, 0, sizeof outrel);
>  	      /* h->dynindx may be -1 if the symbol was marked to

I believe that to be fully correct here you must consider the
alignment of the program segment into which the output section is
being placed.  This can be approximated by considering the alignment
of the output section.

Ian

Re: [PATCH] Re: binutils: "unexpected reloc type 0x17" on sparc

[Tomasz]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]

On Fri, 29 Jun 2001, Jakub Jelinek wrote:
[..]
> That's what elf64-sparc.c is already doing, wonder why it was missing in
> elf32-sparc.c.
> Tomasz, does the following patch help?
> While writing it, I've noticed someone added support for R_SPARC_UA64 into
> elf32-sparc.c. That does not make sense to me in the light that sparc32 is
> not supporting R_SPARC_64 either. Simply putting anything but assembly time
> constant into .xword, .uaxword or .8byte is bad assembly on SPARC 32bit.
> As far as glibc is concerned, if you show me a real-world DSO which really
> needs R_SPARC_UA16 or R_SPARC_UA32, then I'll happily add those relocs to
> sparc/sparc32/dl-machine.h, but the libstdc++ Artur mailed me had just
> R_SPARC_UA32 with all r_offsets divisible by 4.

Seems patche prepared by you Jakub works correctly. After patching
binutils and recompile gcc (mangled libstdc++) and glibc on all pass
correctly.

Thank you.

BTW. Anyone have somewhere startup binaries generated as linux elf 64bit
for usparc ? (glibc, gcc, binutils, shell and few more usualy used).
Or if not is it possible now crosscompile this binaries (is glibc and some
other software is ready for try prepare this kind enviroment ?)

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

Re: [PATCH] Re: binutils: "unexpected reloc type 0x17" on sparc

[David S. Miller]

Ian Lance Taylor writes:
 > Jakub Jelinek <jakub@redhat.com> writes:
 > > As far as glibc is concerned, if you show me a real-world DSO which really
 > > needs R_SPARC_UA16 or R_SPARC_UA32, then I'll happily add those relocs to
 > > sparc/sparc32/dl-machine.h, but the libstdc++ Artur mailed me had just
 > > R_SPARC_UA32 with all r_offsets divisible by 4.
 > 
 > Do it now.  Why wait until somebody has trouble?  It's probably easy
 > to create a C test case using attribute((__packed__)).

Jakub, Ian is right.  Even though such examples are silly, they are
technically legal.

Later,
David S. Miller
davem@redhat.com

Re: [PATCH] Re: binutils: "unexpected reloc type 0x17" on sparc

[Ben Collins]

On Fri, Jun 29, 2001 at 09:30:55PM +0200, Tomasz K?oczko wrote:
> 
> BTW. Anyone have somewhere startup binaries generated as linux elf 64bit
> for usparc ? (glibc, gcc, binutils, shell and few more usualy used).
> Or if not is it possible now crosscompile this binaries (is glibc and some
> other software is ready for try prepare this kind enviroment ?)

Debian unstable has gcc-3.0-sparc64, libc6-dev-sparc64 (the normal
binutils supports elf64_sparc). You can probably alien the .deb's for
redhat usage:

ftp://ftp.debian.org/debian/pool/main/g/gcc-3.0/

ftp://ftp.debian.org/debian/pool/main/g/glibc/

Look for the *_sparc.deb's.

Ben

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'

Re: Commited patch for elf*-sparc.c (was binutils: "unexpected reloc type 0x17" on sparc)

[Richard Henderson]

On Wed, Jul 11, 2001 at 10:20:24PM +0200, Jakub Jelinek wrote:
> I added an flags & SEC_ALLOC check instead (which means e.g. that we no
> longer output useless .rela.stab on sparc when nobody uses it)

For dwarf2 sections, gdb _should_ use the reloc sections.
It's got no other way to get at the information in question.

Non-allocated output sections should create non-allocated
rela sections.


r~

Re: Commited patch for elf*-sparc.c (was binutils: "unexpected reloc type 0x17" on sparc)

[Jakub Jelinek]

On Wed, Jul 11, 2001 at 01:43:49PM -0700, Richard Henderson wrote:
> On Wed, Jul 11, 2001 at 10:20:24PM +0200, Jakub Jelinek wrote:
> > I added an flags & SEC_ALLOC check instead (which means e.g. that we no
> > longer output useless .rela.stab on sparc when nobody uses it)
> 
> For dwarf2 sections, gdb _should_ use the reloc sections.

What for?
Apparently neither i386 nor IA-64 use .rela.debug_info etc. reloc sections
nor does gdb AFAIK use them.

> It's got no other way to get at the information in question.

It took me less than a day to write dwarf2 relocator for the prelink
program.
The relocation rules are there fairly easy and the format is very clear on
what should and what should not be relocated (in .debug_info DW_FORM_addr
format attributes and DW_OP_addr arguments , in .debug_line DW_LNE_set_address,
in .debug_aranges always the first of the address/len pair, in .debug_loc
DW_OP_addr arguments should be relocated).

	Jakub

Re: Commited patch for elf*-sparc.c (was binutils: "unexpected reloc type 0x17" on sparc)

[Richard Henderson]

On Wed, Jul 11, 2001 at 06:04:23PM -0400, Jakub Jelinek wrote:
> > For dwarf2 sections, gdb _should_ use the reloc sections.
> 
> What for?

Because otherwise gdb doesn't know what the address for a given
symbol should be.  All it has is a big fat 0 because the symbol
was resolved by ld to some external DSO.

GDB should take the .rela.debug_* sections and apply them to it's
local copy of .debug_info using the same rules used by ld.so.


r~

Commited patch for elf*-sparc.c (was binutils: "unexpected reloc type 0x17" on sparc)

[Jakub Jelinek]

On Fri, Jun 29, 2001 at 09:59:36AM -0700, Ian Lance Taylor wrote:
> I believe that to be fully correct here you must consider the
> alignment of the program segment into which the output section is
> being placed.  This can be approximated by considering the alignment
> of the output section.

Here is what I've commited.
I added an flags & SEC_ALLOC check instead (which means e.g. that we no
longer output useless .rela.stab on sparc when nobody uses it) and ALLOCed
section VMAs (note that at that point the final addresses are already
computed) will be at least page size aligned, so there is no need to check
it (especially when it could pesimize things).

2001-07-11  Jakub Jelinek  <jakub@redhat.com>

	* elf32-sparc.c (_bfd_sparc_elf_howto_table): Remove support for
	R_SPARC_UA64.
	(elf32_sparc_check_relocs): Likewise.
	Only create .rela section for alloced sections in shared libraries.
	(elf32_sparc_relocate_section): Likewise.
	Remove redundant check.
	Optimize unaligned reloc usage.
	* elf64-sparc.c (sparc64_elf_relocate_section): Remove redundant
	check.

	* testsuite/gas/sparc/unalign.s: Remove .uaxword test.
	* testsuite/gas/sparc/unalign.d: Adjust accordingly.

--- bfd/elf32-sparc.c.jj	Fri Jun 29 11:58:58 2001
+++ bfd/elf32-sparc.c	Wed Jul 11 16:59:53 2001
@@ -120,7 +120,7 @@ reloc_howto_type _bfd_sparc_elf_howto_ta
   HOWTO(R_SPARC_NONE,      0,0, 0,false,0,complain_overflow_dont,    bfd_elf_generic_reloc,  "R_SPARC_NONE",    false,0,0x00000000,true),
   HOWTO(R_SPARC_NONE,      0,0, 0,false,0,complain_overflow_dont,    bfd_elf_generic_reloc,  "R_SPARC_NONE",    false,0,0x00000000,true),
   HOWTO(R_SPARC_NONE,      0,0, 0,false,0,complain_overflow_dont,    bfd_elf_generic_reloc,  "R_SPARC_NONE",    false,0,0x00000000,true),
-  HOWTO(R_SPARC_UA64,      0,4,64,false,0,complain_overflow_bitfield,bfd_elf_generic_reloc,  "R_SPARC_UA64",    false,0,(~ (bfd_vma)0), true),
+  HOWTO(R_SPARC_UA64,      0,0, 0,false,0,complain_overflow_dont,    sparc_elf_notsupported_reloc,  "R_SPARC_UA64",    false,0,0x00000000,true),
   HOWTO(R_SPARC_UA16,      0,1,16,false,0,complain_overflow_bitfield,bfd_elf_generic_reloc,  "R_SPARC_UA16",    false,0,0x0000ffff,true),
   HOWTO(R_SPARC_REV32,     0,2,32,false,0,complain_overflow_bitfield,bfd_elf_generic_reloc,  "R_SPARC_REV32",   false,0,0xffffffff,true),
 };
@@ -554,11 +554,10 @@ elf32_sparc_check_relocs (abfd, info, se
 	case R_SPARC_LO10:
 	case R_SPARC_UA16:
 	case R_SPARC_UA32:
-	case R_SPARC_UA64:
 	  if (h != NULL)
 	    h->elf_link_hash_flags |= ELF_LINK_NON_GOT_REF;
 
-	  if (info->shared)
+	  if (info->shared && (sec->flags & SEC_ALLOC))
 	    {
 	      /* When creating a shared object, we must copy these
                  relocs into the output file.  We create a reloc
@@ -1223,7 +1222,6 @@ elf32_sparc_relocate_section (output_bfd
 			  || r_type == R_SPARC_LO10
 			  || r_type == R_SPARC_UA16
 			  || r_type == R_SPARC_UA32
-			  || r_type == R_SPARC_UA64
 			  || ((r_type == R_SPARC_PC10
 			       || r_type == R_SPARC_PC22)
 			      && strcmp (h->root.root.string,
@@ -1412,8 +1410,7 @@ elf32_sparc_relocate_section (output_bfd
 	case R_SPARC_LO10:
 	case R_SPARC_UA16:
 	case R_SPARC_UA32:
-	case R_SPARC_UA64:
-	  if (info->shared)
+	  if (info->shared && (input_section->flags & SEC_ALLOC))
 	    {
 	      Elf_Internal_Rela outrel;
 	      boolean skip;
@@ -1463,6 +1460,28 @@ elf32_sparc_relocate_section (output_bfd
 	      outrel.r_offset += (input_section->output_section->vma
 				  + input_section->output_offset);
 
+	      /* Optimize unaligned reloc usage now that we know where
+		 it finally resides.  */
+	      switch (r_type)
+		{
+		case R_SPARC_16:
+		  if (outrel.r_offset & 1)
+		    r_type = R_SPARC_UA16;
+		  break;
+		case R_SPARC_UA16:
+		  if (!(outrel.r_offset & 1))
+		    r_type = R_SPARC_16;
+		  break;
+		case R_SPARC_32:
+		  if (outrel.r_offset & 3)
+		    r_type = R_SPARC_UA32;
+		  break;
+		case R_SPARC_UA32:
+		  if (!(outrel.r_offset & 3))
+		    r_type = R_SPARC_32;
+		  break;
+		}
+
 	      if (skip)
 		memset (&outrel, 0, sizeof outrel);
 	      /* h->dynindx may be -1 if the symbol was marked to
@@ -1535,12 +1554,8 @@ elf32_sparc_relocate_section (output_bfd
 	      ++sreloc->reloc_count;
 
 	      /* This reloc will be computed at runtime, so there's no
-                 need to do anything now, unless this is a RELATIVE
-                 reloc in an unallocated section.  */
-	      if (skip
-		  || (input_section->flags & SEC_ALLOC) != 0
-		  || ELF32_R_TYPE (outrel.r_info) != R_SPARC_RELATIVE)
-		continue;
+                 need to do anything now.  */
+	      continue;
 	    }
 	  break;
 
@@ -2024,7 +2039,7 @@ elf32_sparc_object_p (abfd)
     }
   else if (elf_elfheader (abfd)->e_flags & EF_SPARC_LEDATA)
     return bfd_default_set_arch_mach (abfd, bfd_arch_sparc,
-                                      bfd_mach_sparc_sparclite_le);
+				      bfd_mach_sparc_sparclite_le);
   else
     return bfd_default_set_arch_mach (abfd, bfd_arch_sparc, bfd_mach_sparc);
 }
--- bfd/elf64-sparc.c.jj	Fri Jun 29 11:58:58 2001
+++ bfd/elf64-sparc.c	Wed Jul 11 16:57:38 2001
@@ -2283,12 +2283,8 @@ sparc64_elf_relocate_section (output_bfd
 		++sreloc->reloc_count;
 
 		/* This reloc will be computed at runtime, so there's no
-		   need to do anything now, unless this is a RELATIVE
-		   reloc in an unallocated section.  */
-		if (skip
-		    || (input_section->flags & SEC_ALLOC) != 0
-		    || ELF64_R_TYPE_ID (outrel.r_info) != R_SPARC_RELATIVE)
-		  continue;
+		   need to do anything now.  */
+		continue;
 	      }
 	    break;
 	    }
--- gas/testsuite/gas/sparc/unalign.s.jj	Fri Jun  1 23:50:16 2001
+++ gas/testsuite/gas/sparc/unalign.s	Wed Jul 11 15:09:08 2001
@@ -7,9 +7,6 @@ foo:
 	.byte 0x2
 	.uahalf		jim
 	.byte 0x3
-	.uaxword	harry
 	.byte 0x4
 	.byte 0x5
 	.byte 0x6
-
-
--- gas/testsuite/gas/sparc/unalign.d.jj	Sun Jun  3 02:18:03 2001
+++ gas/testsuite/gas/sparc/unalign.d	Wed Jul 11 15:19:05 2001
@@ -12,7 +12,4 @@ Disassembly of section .data:
 			1: R_SPARC_UA32	fred
    4:	00 02 00 00 	(unimp|illtrap)  0x20000
 			6: R_SPARC_UA16	jim
-   8:	03 00 00 00 	sethi  %hi\(0\), %g1
-			9: R_SPARC_UA64	harry
-   c:	00 00 00 00 	(unimp|illtrap)  0
-  10:	00 04 05 06 	(unimp|illtrap)  0x40506
+   8:	03 04 05 06 	sethi  %hi\(0x10141800\), %g1


	Jakub