thr3ads.net - llvm dev - [LLVMdev] [lld] question on ELF section formating [Jul 2014]

If this information is useful, please help other people find it:
Share via:

Daniel Stewart

2014-Jul-28 20:53 UTC

[LLVMdev] [lld] question on ELF section formating

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140728/a1bf5618/attachment.html>

Shankar Easwaran

2014-Jul-28 21:30 UTC

head link

[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         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/e3987e64/attachment.html>

Daniel Stewart

2014-Jul-28 21:42 UTC

head link

[LLVMdev] [lld] question on ELF section formating

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>

Reasonably Related Threads

Search for more possibly parallel threads

llvm dev - Jul 2014 - [LLVMdev] [lld] question on ELF section formating

[LLVMdev] [lld] question on ELF section formating

[LLVMdev] [lld] question on ELF section formating

[LLVMdev] [lld] question on ELF section formating

Reasonably Related Threads