[Bug ld/22903] [AArch64] Insufficient veneer stub alignment

[pexu at sourceware dot mail.kapsi.fi]

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

--- Comment #4 from Pekka Seppänen <pexu at sourceware dot mail.kapsi.fi> ---
Hi.

My apologies for not noticing the branch between the sections; I was not aware
of it even one was just in front of my eyes (it was right after a lenghty data
table, and objdump considered the branch bytecode as data). I was also talking
nonsense about the -fpic and -fpie, and they do not obviously have anything to
do with this (as the limiting factor is simply the maximum branch +-128M reach)
-- an another issue was haunting my mind and I accidentally mixed things up.

Anyway, I tried the Nick's patch, but unfortunately it does not work: If the
offsetted branch address crosses 32/64-bit boundary, things will go horribly
wrong: the upper half is either replaced by a nop bytecode or left out, and the
branch takes a fatal dive to the unknow. If I revert back to a week or so old
GCC and binutils 2.30, the addresses are again valid.

This very unfortunate effect can be actually seen in the testcase, that the
patch modifies.

0000000000001000 <_start>:
    [ ... ]
    100c:       1400000d        b       1040 <__bar_veneer+0x14>
    1010:       d503201f        nop

0000000000001014 <__bar2_veneer>:
    1014:       58000090        ldr     x16, 1024 <__bar2_veneer+0x10>
    1018:       10000011        adr     x17, 1018 <__bar2_veneer+0x4>
    101c:       8b110210        add     x16, x16, x17
    1020:       d61f0200        br      x16
    1024:       ffffefec        .word   0xffffefec
    1028:       d503201f        .word   0xd503201f # <-- should be 0x000000fe

000000000000102c <__bar_veneer>:
    102c:       58000090        ldr     x16, 103c <__bar_veneer+0x10>
    1030:       10000011        adr     x17, 1030 <__bar_veneer+0x4>
    1034:       8b110210        add     x16, x16, x17
    1038:       d61f0200        br      x16
    103c:       ffffefd0        .word   0xffffefd0
    # <-- should have .word 0x000000fe, and not just left out.


(Testcase attached, I used the latest GCC and binutils-gdb trunk.)


Seeing the complexity hiding in the little details, I guess I'll just rework my
approach so that there'll be no veneering necessary. Maybe the best thing to do
would be to create a new directive, that would allow user to place the stubs at
a convenient location (like .ltorg) and perhaps specify the filler, unless the
default is suitable.

I have no doubt that someone is exploiting the de facto that codeflow should be
contiguous between sections, so I guess the default case for the branches over
stubs have to stay. When dealing with a highly space limited target it is
useful, while obviously a bit dangerous, to let the linker fill the gaps
between data and code structures that are somewhat small, but have a large
alignment constraints (MMU, exception tables etc.). In that case all such
branching is, if not harmful, just wasted space.

I could not also think of any case where the excution would land back to the
section branch. The only case I could figure, would have to be some sort of
terrible hack (say, the section branch would occur at a stage N translation
border, and e.g. for that particular page Access Flag would be unset), where an
exception handing code would do something magic, and then return to the next
instruction. In that case doing a nop and branch (instead of branch and nop)
would do the trick, but obviously that is only one of the possible combinations
and therefore just a solution to a problem, that really does not exist (or
should ever exist, if you ask me).

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