[Bug gas/25599] gas generates invalid PCREL60B relocation offset with brl.call

[danglin at gcc dot gnu.org]

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

John David Anglin <danglin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |danglin at gcc dot gnu.org

--- Comment #2 from John David Anglin <danglin at gcc dot gnu.org> ---
For some reason my responses to Nick's questions bounced.

Documentation on ia64 relocs is here:
https://refspecs.linuxfoundation.org/elf/IA64-SysV-psABI.pdf

On 2020-04-08 8:57 a.m., nickc at redhat dot com wrote:
>   I am afraid that I am totally unfamiliar with the IA64 ABI, so if my
>   questions below do not make sense, then please forgive me:
>
>   1.  Is it the case that all instances of the PCREL60B reloc are wrong
>       or is it only under certain circumstances ?  If it is under
>       certain circumstances, then what are they ?

I believe the issue applies to all instances.  The reloc just isn't tested.

>
>   2.  Are other, similar relocs affected ?

I believe the PCREL21B works properly.

>
>   3.  Does this problem only apply to the HP-UX targeted version of the
>       IA64 assembler, or does it apply to other versions too ?  eg
>       ia64-linux, ia64-netbsd, etc.

HP-UX ld handles calls to "weak" functions differently from GNU ld.  The big
difference is calls to "weak" functions don't go through the PLT.  Currently,
calls to weak functions use the PCREL21B relocation.

When gcc switched to building with g++, this resulted in the gcc build using
weak functions.  There's no garbage collection in the HP linker (i.e., linkonce
support), so some calls ended up exceeding the maximum branch distance of the
PCREL21B relocation.  This is a particular problem when stage1 is built
with -O0.  The cc1 and cc1plus binaries are huge.

Given the above, the simplest solution seemed to be to add a long call feature
using the PCREL60B relocation.  However, Peter found that the GNU tools don't
appear to handle the relocation correctly.

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