This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


"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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]