Re: gnu ld problem with sparc solaris 2.8 assembler (fwd)

[Ted Merrill]

oops, no address@hidden

---------- Forwarded message ----------
Date: Thu, 19 Oct 2000 21:17:31 -0700 (PDT)
From: Ted Merrill <address@hidden>
To: Nick Clifton <address@hidden>
Cc: address@hidden
Subject: Re: gnu ld problem with sparc solaris 2.8 assembler

Thanks Nick, for your help.

There was another change that also needs to be made also to binutils-2.10
(and earlier i think!).  See below for description.
Now my static function pointers are being initialized with the correct
value instead of zero.
This seems to have fixed my problem! although i can't swear it is really
the totally correct fix..... and i have apprehension of what other bugs
lurk.
I'm doing all our compilations with gnu as now, and the links with gnu ld...
but if we get a third party object library we have to use then who knows
what other problems of this sort we might find.

Is there someone in your organization or that you know who can cast
a blessing on the fix and get into a future release?
Is there anyone in sun?

Is there an organized list of bugs somewhere?

Thanks again,
Ted Merrill
ArrayComm, Inc.


On Thu, 19 Oct 2000, Nick Clifton wrote:

> 
> Anyway, the problem here is obvious.  One assembler is producing a
> R_SPARC_UA32 reloc to initialise Value and the other is producing a
> R_SPARC_32 reloc.  So it would seem that the GNU linker is not
> handling the R_SPARC_UA32 reloc correctly.
> 
> These relocs are generated as a result of the inputto the assembler
> which looks like this: 
> 
>   Value:
>       .uaword FooBar
> 
> Which is intended to allocate an unaligned word value.
> 
> There is code in the current GNU linker sources which is supposed to
> handle the R_SPARC_UA32 reloc, so maybe it is a case that you are
> using an older version of the linker.  You say that the problem is
> still present if you use the 2.10 sources ?  One thing that I did see
> in the current sources is this (in bfd/elf32-sparc.c):
> 
> static CONST struct elf_reloc_map sparc_reloc_map[] =
> {
>   { BFD_RELOC_NONE, R_SPARC_NONE, },
>   ...
>   { BFD_RELOC_SPARC_WDISP22, R_SPARC_WDISP22 },
>   /* ??? Doesn't dwarf use this?  */
> /*{ BFD_RELOC_SPARC_UA32, R_SPARC_UA32 }, not used?? */
>   {BFD_RELOC_SPARC_10, R_SPARC_10},
>   ....
> };
> 
> It would appear that no-one thought that the UA32 reloc would be used.
> If you try uncommenting this line and then rebuilding the linker, does
> this solve the problem ?
> 

I uncommented that line in the binutils 2.10 source and remade it,
but it made no difference.

In bfd/elf32-sparc.c i noticed that the following looked rather different:

  HOWTO(R_SPARC_UA32,      0,0,00,false,0,complain_overflow_dont,    bfd_elf_gen
eric_reloc,  "R_SPARC_UA32",    false,0,0x00000000,true),
  HOWTO(R_SPARC_32,        0,2,32,false,0,complain_overflow_bitfield,bfd_elf_gen
eric_reloc,  "R_SPARC_32",      false,0,0xffffffff,true),

type, rightshift, size,
    what does it mean for size to be 0 or 2? 
bitsize,
    ... this clearly should be 32 and not 00
pc_relative, bitpos, complain_on_overflow,
    ... i guess _dont should be safe?
special_function, name, partial_inplace, src_mask, dst_mask
    ... dst_mask should be 0xffffffff instead of 0 !
pcrel_offset

--> i guess that all should be the same except for the enum/name fields and
possibly the overflow handler?.

I changed the UA32 HOWTO in bfd/elf32-sparc.c to be same as the _32 handler
except for the enum and name.
That fixed it!

NOTE: a similar fix should be made to other sparc formats (coff and ? elf64?)