[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: bfd_get_relocated_section_contents on hppa and ia64

From: Camm Maguire
Subject: [Gcl-devel] Re: bfd_get_relocated_section_contents on hppa and ia64
Date: Tue, 26 Oct 2010 16:06:09 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Greetings, and thanks so much!

Nick Clifton <address@hidden> writes:

> Hi Camm,
>> Greetings!  I can't seem to find documentation anywhere on the sparc64
>> R_SPARC_OLO10 reloc, sometimes reported as a R_SPARC_LO10 and a
>> R_SPARC_13.
> I think that R_SPARC_0LO10 and R_SPARC_LO10 are subtly different...
>> I know there is a special addend encoded in the reloc
>> type.  Can you explain to me or point out to me how this reloc is
>> supposed to work?
> I am not a Sparc expert, but I will give it a go.  I could not find
> any actual documentation on Sparc relocs, so I have resorted to
> looking in the sources.  In gas/doc/c-sparc.texi it says:
>   "When assembling for 64-bit, and a secondary constant
>    addend is specified in an address expression that would
>    normally generate an R_SPARC_LO10 relocation, the
>    assembler will emit an R_SPARC_OLO10 instead."
> So I think that R_SPARC_OLO10 is a slight variation on the
> R_SPARC_LO10 reloc.  Looking in
> bfd/elfxx-sparc.c:_bfd_sparc_elf_relocate_section() I see that the
> reloc is implemented as:
>    x = (x & ~(bfd_vma) 0x1fff) | (relocation & 0x1fff);
> Ie it clears the bottom 13 bits of the instruction and then inserts
> the value of the relocation into those bits.  (I assume that this
> relocation is being applied to a Sparc bitwise logical instruction
> which has a signed immediate value in its bottom 13 bits).
> This seems to be very similar to the R_SPARC_LO10 relocation, except
> that that one appears to affect only the bottom 10 bits of the
> instruction.
> There is one other interesting point.  In the
> _bfd_sparc_elf_howto_table in elfxx-sparc.c the implementation of the
> R_SPARC_OLO10 reloc is assigned to the sparc_elf_notsup_reloc()
> function.  Thus it may be that it is a deprecated reloc that should no
> longer be used.

Thanks so much!

I also found this:


This patch adds support for R_SPARC_OLO10 relocation.
It is in fact a compound relocation equal to R_SPARC_LO10 and R_SPARC_13
with no symbol applied on top of it, so I have modelled the support from
elf64-mips.c which already supports compound relocations.
The syntax in the assembler is obvious:
        ld [%o1 + %lo(ab+12)], %o1
will generate normal R_SPARC_LO10 relocation with addend 12, while
        ld [%o1 + %lo(ab+12) + 24], %o1
will generate R_SPARC_OLO10 relocation with addend 12 and secondary addend
(stored in upper 24 bits of ELF64_R_TYPE) 24.
slurp_reloc_table will read all OLO10 relocations as LO10 and 13, because
there is no place to store secondary addend in arelent.
OLO10 is IMHO very useful, because gcc can now add constants to symbols
without having to worry about the symbol alignment. It should speed up
access to array members at constant offsets if a routine accesses more than
two different ones.

and indeed in my testing the reloc appears correctly implemented in
this way, i.e. *store* the low 10 bits, then *add* the special addend
in a 13 bit field.  This does not appear consistent with the 0
src-mask in the R_SPARC_13 howto in elf64-sparc.c:

  HOWTO(R_SPARC_OLO10,     0,2,13,FALSE,0,complain_overflow_signed,  
sparc_elf_notsup_reloc, "R_SPARC_OLO10",   FALSE,0,0x00001fff,TRUE),
0,2,13,FALSE,0,complain_overflow_bitfield,bfd_elf_generic_reloc,  "R_SPARC_13", 
  HOWTO(R_SPARC_LO10,      0,2,10,FALSE,0,complain_overflow_dont,    
bfd_elf_generic_reloc,  "R_SPARC_LO10",    FALSE,0,0x000003ff,TRUE),

which is probably why gcl cannot relocate native code using bfd on
sparc64, but appears to be able to (so far) with the native relocation
facility built into gcl itself.

Take care,
Camm Maguire                                        address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]