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

Hi Tim,

You seem to be working around BLX support on ARM, and this linker
error has cropped up on our buildbot:

http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/3526

llvm/tools/clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp:

(.text._ZN5clang4ento24ProgramStatePartialTraitIN4llvm12ImmutableMapIPKNS0_7SymExprEN12_GLOBAL__N_111ReallocPairENS2_16ImutKeyValueInfoIS6_S8_EEEEE13DeleteContextEPv+0x88):

relocation truncated to fit: R_ARM_THM_JUMP24 against symbol `operator
delete(void*)@@GLIBCXX_3.4' defined in .text section in
/usr/lib/gcc/arm-linux-gnueabihf/4.8/libstdc++.so

If I read the AAELF ABI document correctly, that relocation is used
when the linker is building a veneer for under-reaching branches,
which seems to be one of your changes (269101), though that was
supposed to be MachO only.

Do you have any ideas on the issue?

cheers,
-renato

PS: I'm bisecting it right now, but it's self hosted + compiler-rt, so
it will take a while. Also, I fear whatever I find will be just
uncovering the problem, not causing it.

FYI, the bot now built successfully, which is worrying. It's also
elusive to my bisect attempts so far.

Unless there was a fix that I failed to see, we could be dealing with
a self-hosting heisenbug... :S

--renato

On 18 May 2016 at 12:12, Renato Golin <renato.golin at linaro.org>
wrote:
> Hi Tim,
>
> You seem to be working around BLX support on ARM, and this linker
> error has cropped up on our buildbot:
>
>
http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/3526
>
> llvm/tools/clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp:
>
>
(.text._ZN5clang4ento24ProgramStatePartialTraitIN4llvm12ImmutableMapIPKNS0_7SymExprEN12_GLOBAL__N_111ReallocPairENS2_16ImutKeyValueInfoIS6_S8_EEEEE13DeleteContextEPv+0x88):
>
> relocation truncated to fit: R_ARM_THM_JUMP24 against symbol `operator
> delete(void*)@@GLIBCXX_3.4' defined in .text section in
> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libstdc++.so
>
> If I read the AAELF ABI document correctly, that relocation is used
> when the linker is building a veneer for under-reaching branches,
> which seems to be one of your changes (269101), though that was
> supposed to be MachO only.
>
> Do you have any ideas on the issue?
>
> cheers,
> -renato
>
> PS: I'm bisecting it right now, but it's self hosted + compiler-rt,
so
> it will take a while. Also, I fear whatever I find will be just
> uncovering the problem, not causing it.

On 18 May 2016 at 04:12, Renato Golin via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> relocation truncated to fit: R_ARM_THM_JUMP24 against symbol `operator
> delete(void*)@@GLIBCXX_3.4' defined in .text section in
> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libstdc++.so
I don't suppose you could grab a -save-temps output for MallocChecker.cpp?
> If I read the AAELF ABI document correctly, that relocation is used
> when the linker is building a veneer for under-reaching branches,
> which seems to be one of your changes (269101), though that was
> supposed to be MachO only.
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 not aware of any better candidate than r269101 for a cause, but
I'm still rather confused about how. Hopefully the intermediate files
will shed some light on at least what's wrong.

Cheers.

Tim.

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