llvm dev - Jan 2017 - Got stuck with PC-rel branching

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

Thanks,
Petr

On Thu, Jan 19, 2017 at 8:06 PM, Friedman, Eli <efriedma at
codeaurora.org>
wrote:
> On 1/19/2017 9:11 AM, Peter Bel via llvm-dev wrote:
>
> Hi all,
>
>
>
> I'm trying to make an LLVM backend for the Adapteva's Epiphany E16
CPU
> (used in Parallella board), using CPU0 and some other backends as examples,
> and I've got stuck with branching.
>
> When I'm printing out asm, all branch labels are printed as they should
> be. But when I'm trying to generate obj file, I'm getting zeros
instead of
> PC-related offset in all branch instructions.
>
> In short, what I'm doing:
>
> - Pattern (br bb:$addr) is selected using EpiphanyInstrInfo.td as
> BNONE32(ins jmptarget:$addr), Branch32 class
>
> - Branch32 class is defined in EpiphanyInstrFormats.td with bits<24>
addr,
> which should go into bits{31-8} of the MC instruction. Those bits remain
> zeros after relaxation for some reason.
>
> - jmptarget operand has type OPERAND_PCREL, and uses EncoderMethod
> "getJumpTargetOpValue" defined in EpiphanyMCCodeEmitter. If this
method
> gets MCExpr, it creates fixup, and I can see this fixup in debug.
>
> - Fixup is called fixup_Epiphany_PCREL24, and is defined in
> EpiphanyFixupKinds and EpiphanyAsmBackend, with FKF_IsPCRel flag.
>
>
>
> Can someone please tell me if I am missing something?
>
>
> Are you sure there's actually a problem?  On x86, for example:
>
> $ echo "int f(); int g() { return f(); }" | clang -x c - -o
/tmp/a.o -c &&
> objdump -d /tmp/a.o
>
> /tmp/a.o:     file format elf64-x86-64
>
>
> Disassembly of section .text:
>
> 0000000000000000 <g>:
>    0:   55                      push   %rbp
>    1:   48 89 e5                mov    %rsp,%rbp
>    4:   b0 00                   mov    $0x0,%al
>    6:   e8 00 00 00 00          callq  b <g+0xb>
>    b:   5d                      pop    %rbp
>    c:   c3                      retq
>
> It looks like the call isn't calling the right function, but that's
fine:
> it'll get fixed by the linker.
>
> -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/20170119/e6ff3f3e/attachment.html>

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

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>