[llvm-dev] Got stuck with PC-rel branching

[Peter Bel via llvm-dev]

Sorry for putting this topic up, but can I ask for your advice once again?
I'm getting some very strange errors and I can't really understand why. In
my applyFixup() I have fixup value adjustment, and for fixup PCREL24 I have
the following simple code:

case Epiphany::fixup_Epiphany_PCREL24
  Value = Value << 7;
  break;

When I'm trying to compile a sample binary (any, even without this fixup
type), it "might fail" on
MC/ELFObjectWriter.cpp::executePostLayoutBinding():392, which is called
from MCAssembler.cpp::layout(). If fails on the following line:
const auto &Alias = cast<MCSymbolELF>(A);

"Might fail" - because it doesn't fail every time. I can change some other
completely unrelated piece of code - and suddenly it'll fail. If I'll
change it to smth else, e.g. Value = Value, it won't fail, but it still
"might fail" after some other change. Sometimes it can fail on different
lines, sometimes it can even pass through on the first run and fail on the
second.

I've checked that it fails because MCSymbol &A has A.Kind different from 2 (
SymbolKindELF), usually it's 1 or 0 (COFF or Unknown).
Why it dumbfolded me heavily is because this code runs before applyFixup(), not
after (verified with the debugger), so in general it should not be
affected. Changes made can be purely cosmetic, e.g. adding one more debug
output.

After running the llc through the debugger, the wrong value is placed while
running MCObjectStreamer::flushPendingLabels(), but I failed to find what
causes this failure.

Best regards,
Petr

On Wed, Jan 25, 2017 at 7:02 PM, Peter Bel <upcfrost at gmail.com> wrote:

> Big thanks, i've managed to find what's going on. The thing that
> dumbfolded me a couple of times was that the error was thrown in one of the
> MCAssembler methods, but never in applyFixup() itself.
>
> On Thu, Jan 19, 2017 at 8:46 PM, Friedman, Eli <efriedma at codeaurora.org>
> wrote:
>
>> On 1/19/2017 10:21 AM, Peter Bel wrote:
>>
>>> Hi,
>>>
>>> For the function call - yes, probably. But what about branching inside
>>> one function (standard if-then for example)?
>>>
>>> For example:
>>> echo "int g() { int a = 1; if (a > 3) return 1; return 0; }" | clang -x
>>> c - -o /tmp/a.o -c && objdump -d /tmp/a.o
>>>
>>
>> Yes, the assembler tries to avoid emitting relocations for relative
>> offsets within a section.  See MCAssembler::layout, particularly the bit at
>> the end where it calls applyFixup().
>>
>>
>> -Eli
>>
>> --
>> Employee of Qualcomm Innovation Center, Inc.
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> Linux Foundation Collaborative Project
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170126/6a8a7d90/attachment.html>