llvm dev - May 2016 - BLX relocation regression on Thumb2 bot

On 18 May 2016 at 15:12, Tim Northover <t.p.northover at gmail.com>
wrote:
> I don't suppose you could grab a -save-temps output for
MallocChecker.cpp?
Not from the bot any more. I didn't expect this to be a heisenbug. And
I'm having trouble replicating it on my other machine.

> I think we only produce R_ARM_THM_JUMP24 for tail calls. The veneer is
> then needed if a mode change is required because there's no "bx
(imm)"
> instruction.
I'm curious as to what changed the behaviour, and from what? bx reg?
or non-tail call?

If I manage to reproduce it, I'll post back here.

cheers,
--renato

On 18 May 2016 at 07:33, Renato Golin <renato.golin at linaro.org>
wrote:
>> I think we only produce R_ARM_THM_JUMP24 for tail calls. The veneer is
>> then needed if a mode change is required because there's no
"bx (imm)"
>> instruction.
>
> I'm curious as to what changed the behaviour, and from what? bx reg?
> or non-tail call?
That's the thing: this shouldn't have changed at all recently. We emit
"b.w dest" with an R_ARM_THM_JUMP24 reloc. The linker then needs a
veneer if dest is out of range or an ARM function.

We shouldn't even be *able* to botch that particular relocation:
anything we put in there should be fixable by the linker (assuming
sizeof(text section) < 16MB so that there's room for a veneer, which
is almost certain especially as we're using -ffunction-sections). The
linker error is more of an assertion, really.

Tim.

On 18 May 2016 at 17:32, Tim Northover <t.p.northover at gmail.com>
wrote:
> That's the thing: this shouldn't have changed at all recently. We
emit
> "b.w dest" with an R_ARM_THM_JUMP24 reloc. The linker then needs
a
> veneer if dest is out of range or an ARM function.
Peter has just reminded me the fact that the relocation itself is in
libstdc++, not on the object Clang is producing.

I've opened a bug so that we're aware, and in case anyone sees it
again and manage to reproduce, we may be able to either fix it or
report it to binutils.

https://llvm.org/bugs/show_bug.cgi?id=27813

cheers,
--renato