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

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.

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

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.

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

Are you sure about that, it looked like something in MallocChecker.cpp calling “new” to me. The reverse would be rather odd.

Anyway, hopefully we can blame cosmic rays or gremlins.

Tim.

Are you sure about that, it looked like something in MallocChecker.cpp calling “new” to me. The reverse would be rather odd.

I'm not sure at all!

The failure was in:

clang::ento::ProgramStatePartialTrait<
    llvm::ImmutableMap<
        clang::ento::SymExpr const*,
        (anonymous namespace)::ReallocPair,
        llvm::ImutKeyValueInfo<
            clang::ento::SymExpr const*,
            (anonymous namespace)::ReallocPair
        >
    >

::DeleteContext(void*)

and the relocation error was against libstdc++'s delete. I assumed
this was generated by Clang, so hopefully not a bug in a deprecated
version of GCC/ld/libstdc++.

But without being able to reproduce, or get more information, I'm at a loss.

I'll just blame muons for now... Just keep this in mind if you see a
similar failure, and update the bug with any hint as to how reproduce,
if you find any.

cheers,
--renato