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

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

On 19 May 2016, at 03:03, Renato Golin <renato.golin at linaro.org>
wrote:
> Peter has just reminded me the fact that the relocation itself is in
> libstdc++, not on the object Clang is producing.
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.

On 19 May 2016 at 15:23, Tim Northover <tnorthover at apple.com>
wrote:
> 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