[Bug gas/20427] Solaris rtld on SPARC does not allow R_SPARC_UA64 or R_SPARC_64 relocations in 32-bit executables

[ali_swbugzilla at emvision dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20427

Ali Bahrami <ali_swbugzilla at emvision dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ali_swbugzilla at emvision dot 
com

--- Comment #7 from Ali Bahrami <ali_swbugzilla at emvision dot com> ---
We think it's not a linker bug. The 32 and 64-bit
sparc platform ABIs are distinct, and here, we're talking
about relocations defined for 64-bit objects, but not for
32-bit ones. The error from ld seems legit, and is intended
to catch this case.

The 2 tables of sparc relocations (32 and 64-bit) can be
found here:

   
https://docs.oracle.com/cd/E53394_01/html/E54813/chapter6-54839.html#OSLLGchapter6-62988

This question wouldn't come up if we were discussing x86,
where the 32 and 64-bit relocations are pretty different, but
with sparc, where the 64-bit case is essentially an extension of
the 32-bit case, that's probably less obvious.

Just to be sure, I checked with our resident sparc architecture
expert, and he told us:

    I'm not exactly sure what the question is.

    The relocations are for late binding
    of the value of a symbol.
    Symbol values in a 32-bit program
    cannot be larger than 32-bits, AFAIK.

    Now relocations are a little more complicated,
    because they encode an expression.
    So, we could have relocations that
    encode an expression that is larger
    than 32-bits for a 32-bit program.
    But there has been no need for them,
    so they were never created, AFAIK.

    It would certainly be possible
    to create some 64-bit relocation expressions
    for 32-bit programs.
    I would want to see some better justification
    before creating them, though.
    And some assembler syntax might be necessary
    to disambiguate which relocation should be used
    in some circumstances. 

Which I will simplify to "we haven't needed that relocation
for 32-bit sparc, so it doesn't exist".

Another engineer here mentioned the following:

    For what it's worth, Go's internal linker handles this by
    generating two relocations internally -- one for the lower
    half of the 64-bit value and one for the upper half of the
     64-bit value.

    This tends to work out nicely since you have to load each half
    separately anyway:

        // R_ADDRSPARC64LO (only used on sparc64) resolves to low 32bits of a
        // 64-bit address, by loading the address into a register with two
instructions.
        R_ADDRSPARC64LO
        // R_ADDRSPARC64HI (only used on sparc64) resolves to high 32bits of a
        // 64-bit address, by loading the address into a register with two
instructions.
        R_ADDRSPARC64HI 

That squares with Nick's earlier comment

    Does it, for example, produce two 32-bit relocs, one
    for the lower 32-bits and one for the upper 32-bits ?

-- 
You are receiving this mail because:
You are on the CC list for the bug.