[LLVMdev] [lld] question on ELF section formating

[Daniel Stewart]

Wouldn't all the relocations already be processed by the time we get to
writing a file? Since it appears YAML is correct and the actual executable
is not, I thought that the relocations wouldn't be an issue. But I can go
back and check the relocations again. 

 

What do you mean by "writing content overlapped"? Does this refer to a
particular process that lld does? I haven't modified the ELF writing at all
(at least I don't think I have!). I thought that OutputELFWriter.h was doing
all (or at least the bulk) of the work. I have an
AARch64ExecutbaleWriter.cpp, but it just creates a few got files, it doesn't
actually do any writing that I can tell.

 

Daniel

 

From: Shankar Easwaran [mailto:shankare at codeaurora.org] 
Sent: Monday, July 28, 2014 5:31 PM
To: Daniel Stewart; llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] [lld] question on ELF section formating

 

It could be any of the following issues :-

a) When writing content overlapped ...
b) The way relocations are applied in X86_64 would be different from
AARCH64, so could be in the place how relocations are being processed.

Thanks

Shankar Easwaran

On 7/28/2014 3:53 PM, Daniel Stewart wrote:

I've been adding ELF/AArch64 support to lld based off the existing x86_64
code that is already there in lld. I've been able to compile and link a
simple "Hello World"-type program. However, I'm getting what appears to be a
misplacement/name change of the _start atom. When I do the link, the _start
section gets named __tls_get_addr. The code inside this section appears to
be correct, just the name is wrong. If I output in YAML, it appears to have
the correct name. 
 
 
 
Since I know this is new code that no one has seen, I was just wondering if
anyone might give me a hint as to why this might happen or a good place to
start looking. I'm new to the linker and only have been looking into lld for
about a week. 
 
 
 
The output in YAML for the section in question is:
 
 
 
  - name:            _start
 
    scope:           global
 
    content:         [ 1D, 00, 80, D2, 1E, 00, 80, D2, FD, 03, 00, 91, 
 
                       E5, 03, 00, AA, E1, 03, 40, F9, E2, 23, 00, 91, 
 
                       E6, 03, 00, 91, A0, 00, 00, 58, C3, 00, 00, 58, 
 
                       E4, 00, 00, 58, 00, 00, 00, 94, 00, 00, 00, 94 ]
 
    alignment:       2^3
 
    section-name:    .text
 
    references:      
 
      - kind:            R_AARCH64_CALL26
 
        offset:          40
 
        target:          __plt___libc_start_main
 
      - kind:            R_AARCH64_CALL26
 
        offset:          44
 
        target:          __plt_abort
 
      - kind:            in-group
 
        offset:          0
 
        target:          L030
 
      - kind:            layout-after
 
        offset:          0
 
        target:          '$d.010'
 
 
 
The output during objdump of that section is:
 
 
 
00000000004006d0 <__tls_get_addr>:
 
  4006d0:              d280001d             mov       x29, #0x0
// #0
 
  4006d4:              d280001e             mov       x30, #0x0
// #0
 
  4006d8:              910003fd              mov       x29, sp
 
  4006dc:               aa0003e5             mov       x5, x0
 
  4006e0:              f94003e1              ldr           x1, [sp]
 
  4006e4:              910023e2             add        x2, sp, #0x8
 
  4006e8:              910003e6             mov       x6, sp
 
  4006ec:               580000a0             ldr           x0, 400700
<__tls_get_addr+0x30>
 
  4006f0:               580000c3              ldr           x3, 400708
<__tls_get_addr+0x38>
 
  4006f4:               580000e4             ldr           x4, 400710
<__tls_get_addr+0x40>
 
  4006f8:               97ffffe6                bl            400690
<__libc_start_main at plt>
 
  4006fc:                97ffffe9                bl            4006a0
<abort at plt>
 
  400700:               004008a0             .inst       0x004008a0 ;
undefined
 
  400704:               00000000             .inst       0x00000000 ;
undefined
 
  400708:               00400934             .inst       0x00400934 ;
undefined
 
  40070c:               00000000             .inst       0x00000000 ;
undefined
 
  400710:               004009ac              .inst       0x004009ac ;
undefined
 
  400714:               00000000             .inst       0x00000000 ;
undefined
 
 
 
 
 
Daniel
 
 
 
--
 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
 
 
 
 






_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev






-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
the Linux Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140728/e9834c08/attachment.html>