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/20170125/d585f8ed/attachment.html>
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>
Friedman, Eli via llvm-dev
2017-Jan-26 18:04 UTC
[llvm-dev] Got stuck with PC-rel branching
On 1/26/2017 9:00 AM, Peter Bel wrote:> 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).This sounds like memory corruption of some sort... have you tried asan and/or valgrind? -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/6b7c4d70/attachment-0001.html>