* LD: Cannot add content to ctors section
@ 2020-05-20 9:15 Ben Hirschberg
2020-05-20 11:45 ` H.J. Lu
2020-05-21 4:57 ` Alan Modra
0 siblings, 2 replies; 12+ messages in thread
From: Ben Hirschberg @ 2020-05-20 9:15 UTC (permalink / raw)
To: binutils
Hi!
I have a setup (Alpine Linux with Go executables) where I cannot rely on contents of ".init_array" to be called, but ".ctors" are called by musl-libc's loader.
I am trying to add my constructors (C or ASM) to the ".ctors" section, but after linking my shared object they seem to be moved to ".init_array" (however in Alpine the ".ctors" section stays in the final image but it is empty)
Why is this happening? Can make my array stay in ".ctors" section?
Thanks
Ben
Here is my ASM code:
.intel_syntax noprefix
.text
.section .rodata
.Message:
.string "Constructor called!"
.text
Constructor:
lea rdi, .Message[rip]
jmp puts@PLT
.section .ctors,"a"
__CTOR_LIST__:
.quad Constructor
I run compile and link it but the ctors is empty!
$ gcc ctors.s -c -o ctors.o
$ ld -shared ctors.o -o ctors.so
$ readelf -x 14 /libctors.so
Hex dump of section '.ctors':
0x00003df8 ffffffff ffffffff 00000000 00000000 ................
The content of this email is confidential and intended for the recipient specified in message only. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: LD: Cannot add content to ctors section
2020-05-20 9:15 LD: Cannot add content to ctors section Ben Hirschberg
@ 2020-05-20 11:45 ` H.J. Lu
2020-05-20 11:52 ` Ben Hirschberg
2020-05-21 4:57 ` Alan Modra
1 sibling, 1 reply; 12+ messages in thread
From: H.J. Lu @ 2020-05-20 11:45 UTC (permalink / raw)
To: Ben Hirschberg; +Cc: binutils
On Wed, May 20, 2020 at 2:40 AM Ben Hirschberg <bhirschb@cyberarmor.io> wrote:
>
> Hi!
>
> I have a setup (Alpine Linux with Go executables) where I cannot rely on contents of ".init_array" to be called, but ".ctors" are called by musl-libc's loader.
>
> I am trying to add my constructors (C or ASM) to the ".ctors" section, but after linking my shared object they seem to be moved to ".init_array" (however in Alpine the ".ctors" section stays in the final image but it is empty)
>
> Why is this happening? Can make my array stay in ".ctors" section?
>
> Thanks
> Ben
>
> Here is my ASM code:
>
> .intel_syntax noprefix
> .text
>
> .section .rodata
> .Message:
> .string "Constructor called!"
>
> .text
> Constructor:
> lea rdi, .Message[rip]
> jmp puts@PLT
>
> .section .ctors,"a"
> __CTOR_LIST__:
> .quad Constructor
>
Do it in C with constructor attribute.
--
H.J.
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: LD: Cannot add content to ctors section
2020-05-20 11:45 ` H.J. Lu
@ 2020-05-20 11:52 ` Ben Hirschberg
2020-05-20 12:11 ` H.J. Lu
0 siblings, 1 reply; 12+ messages in thread
From: Ben Hirschberg @ 2020-05-20 11:52 UTC (permalink / raw)
To: H.J. Lu; +Cc: binutils
Yeah, well, if life was so easy...
The original solution was using C with attribute constructor. It it is not working in this scenario because it adds the function to the ".init_array" section and not the ".ctors".
-----Original Message-----
From: H.J. Lu <hjl.tools@gmail.com>
Sent: Wednesday, May 20, 2020 2:45 PM
To: Ben Hirschberg <bhirschb@cyberarmor.io>
Cc: binutils@sourceware.org
Subject: Re: LD: Cannot add content to ctors section
On Wed, May 20, 2020 at 2:40 AM Ben Hirschberg <bhirschb@cyberarmor.io> wrote:
>
> Hi!
>
> I have a setup (Alpine Linux with Go executables) where I cannot rely on contents of ".init_array" to be called, but ".ctors" are called by musl-libc's loader.
>
> I am trying to add my constructors (C or ASM) to the ".ctors" section, but after linking my shared object they seem to be moved to ".init_array" (however in Alpine the ".ctors" section stays in the final image but it is empty)
>
> Why is this happening? Can make my array stay in ".ctors" section?
>
> Thanks
> Ben
>
> Here is my ASM code:
>
> .intel_syntax noprefix
> .text
>
> .section .rodata
> .Message:
> .string "Constructor called!"
>
> .text
> Constructor:
> lea rdi, .Message[rip]
> jmp puts@PLT
>
> .section .ctors,"a"
> __CTOR_LIST__:
> .quad Constructor
>
Do it in C with constructor attribute.
--
H.J.
The content of this email is confidential and intended for the recipient specified in message only. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: LD: Cannot add content to ctors section
2020-05-20 11:52 ` Ben Hirschberg
@ 2020-05-20 12:11 ` H.J. Lu
2020-05-20 12:50 ` Ben Hirschberg
0 siblings, 1 reply; 12+ messages in thread
From: H.J. Lu @ 2020-05-20 12:11 UTC (permalink / raw)
To: Ben Hirschberg; +Cc: binutils
On Wed, May 20, 2020 at 4:52 AM Ben Hirschberg <bhirschb@cyberarmor.io> wrote:
>
> Yeah, well, if life was so easy...
>
> The original solution was using C with attribute constructor. It it is not working in this scenario because it adds the function to the ".init_array" section and not the ".ctors".
>
Why didn't .init_array work?
--
H.J.
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: LD: Cannot add content to ctors section
2020-05-20 12:11 ` H.J. Lu
@ 2020-05-20 12:50 ` Ben Hirschberg
2020-05-20 13:05 ` H.J. Lu
0 siblings, 1 reply; 12+ messages in thread
From: Ben Hirschberg @ 2020-05-20 12:50 UTC (permalink / raw)
To: H.J. Lu; +Cc: binutils
It is not working, because Alpine container images are using musl-libc. The dynamic loader in musl doesn't call the functions in ".init_array", it delegates this requirement to C runtime (crt0.o). It works in case of Alpine executable which was linked against musl's crt0, because musl's crt0 calls ".init_array" functions.
In my project I have a shared object which is loaded into a Go application. Go application does not use crt0.o and does not call ".init_array" functions. They say that it is ok, because this is the responsibility of the dynamic loader. (see this discussion if you're interested https://github.com/golang/go/issues/28909)
I want to do a workaround this issue and put my static constructors into ".ctros" section because it is supported across the board.
-----Original Message-----
From: H.J. Lu <hjl.tools@gmail.com>
Sent: Wednesday, May 20, 2020 3:12 PM
To: Ben Hirschberg <bhirschb@cyberarmor.io>
Cc: binutils@sourceware.org
Subject: Re: LD: Cannot add content to ctors section
On Wed, May 20, 2020 at 4:52 AM Ben Hirschberg <bhirschb@cyberarmor.io> wrote:
>
> Yeah, well, if life was so easy...
>
> The original solution was using C with attribute constructor. It it is not working in this scenario because it adds the function to the ".init_array" section and not the ".ctors".
>
Why didn't .init_array work?
--
H.J.
The content of this email is confidential and intended for the recipient specified in message only. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: LD: Cannot add content to ctors section
2020-05-20 12:50 ` Ben Hirschberg
@ 2020-05-20 13:05 ` H.J. Lu
2020-05-20 13:21 ` Ben Hirschberg
0 siblings, 1 reply; 12+ messages in thread
From: H.J. Lu @ 2020-05-20 13:05 UTC (permalink / raw)
To: Ben Hirschberg; +Cc: binutils
On Wed, May 20, 2020 at 5:50 AM Ben Hirschberg <bhirschb@cyberarmor.io> wrote:
>
> It is not working, because Alpine container images are using musl-libc. The dynamic loader in musl doesn't call the functions in ".init_array", it delegates this requirement to C runtime (crt0.o). It works in case of Alpine executable which was linked against musl's crt0, because musl's crt0 calls ".init_array" functions.
>
> In my project I have a shared object which is loaded into a Go application. Go application does not use crt0.o and does not call ".init_array" functions. They say that it is ok, because this is the responsibility of the dynamic loader. (see this discussion if you're interested https://github.com/golang/go/issues/28909)
>
> I want to do a workaround this issue and put my static constructors into ".ctros" section because it is supported across the board.
You should file a bug report against musl-libc. If it doesn't support
.init_array in a shared object,
it is pretty much broken and shouldn't be used at all.
--
H.J.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: LD: Cannot add content to ctors section
2020-05-20 13:05 ` H.J. Lu
@ 2020-05-20 13:21 ` Ben Hirschberg
2020-05-20 13:22 ` H.J. Lu
0 siblings, 1 reply; 12+ messages in thread
From: Ben Hirschberg @ 2020-05-20 13:21 UTC (permalink / raw)
To: H.J. Lu; +Cc: binutils
I don't want to blame here anyone, both musl guys and the people at Go have their arguments.
I am rather looking for a workaround and trying to pick your brain.
Is there a way I can tell linker not to put this function in .init_array but .ctors?
The content of this email is confidential and intended for the recipient specified in message only. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: LD: Cannot add content to ctors section
2020-05-20 13:21 ` Ben Hirschberg
@ 2020-05-20 13:22 ` H.J. Lu
2020-05-20 13:35 ` Ben Hirschberg
0 siblings, 1 reply; 12+ messages in thread
From: H.J. Lu @ 2020-05-20 13:22 UTC (permalink / raw)
To: Ben Hirschberg; +Cc: binutils
On Wed, May 20, 2020 at 6:21 AM Ben Hirschberg <bhirschb@cyberarmor.io> wrote:
>
> I don't want to blame here anyone, both musl guys and the people at Go have their arguments.
>
> I am rather looking for a workaround and trying to pick your brain.
>
> Is there a way I can tell linker not to put this function in .init_array but .ctors?
Use a very old (maybe broken) linker.
--
H.J.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: LD: Cannot add content to ctors section
2020-05-20 13:22 ` H.J. Lu
@ 2020-05-20 13:35 ` Ben Hirschberg
2020-05-20 17:00 ` H.J. Lu
0 siblings, 1 reply; 12+ messages in thread
From: Ben Hirschberg @ 2020-05-20 13:35 UTC (permalink / raw)
To: H.J. Lu; +Cc: binutils
Could I add my own crt0 to my shared object and call my .init_array functions?
________________________________
From: H.J. Lu <hjl.tools@gmail.com>
Sent: Wednesday, May 20, 2020 4:22:37 PM
To: Ben Hirschberg <bhirschb@cyberarmor.io>
Cc: binutils@sourceware.org <binutils@sourceware.org>
Subject: Re: LD: Cannot add content to ctors section
On Wed, May 20, 2020 at 6:21 AM Ben Hirschberg <bhirschb@cyberarmor.io> wrote:
>
> I don't want to blame here anyone, both musl guys and the people at Go have their arguments.
>
> I am rather looking for a workaround and trying to pick your brain.
>
> Is there a way I can tell linker not to put this function in .init_array but .ctors?
Use a very old (maybe broken) linker.
--
H.J.
The content of this email is confidential and intended for the recipient specified in message only. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: LD: Cannot add content to ctors section
2020-05-20 13:35 ` Ben Hirschberg
@ 2020-05-20 17:00 ` H.J. Lu
0 siblings, 0 replies; 12+ messages in thread
From: H.J. Lu @ 2020-05-20 17:00 UTC (permalink / raw)
To: Ben Hirschberg; +Cc: binutils
On Wed, May 20, 2020 at 6:35 AM Ben Hirschberg <bhirschb@cyberarmor.io> wrote:
>
> Could I add my own crt0 to my shared object and call my .init_array functions?
> ________________________________
> From: H.J. Lu <hjl.tools@gmail.com>
> Sent: Wednesday, May 20, 2020 4:22:37 PM
> To: Ben Hirschberg <bhirschb@cyberarmor.io>
> Cc: binutils@sourceware.org <binutils@sourceware.org>
> Subject: Re: LD: Cannot add content to ctors section
>
> On Wed, May 20, 2020 at 6:21 AM Ben Hirschberg <bhirschb@cyberarmor.io> wrote:
> >
> > I don't want to blame here anyone, both musl guys and the people at Go have their arguments.
> >
> > I am rather looking for a workaround and trying to pick your brain.
> >
> > Is there a way I can tell linker not to put this function in .init_array but .ctors?
>
> Use a very old (maybe broken) linker.
>
I was told that what Go does was wrong. There is nothing linker can do.
--
H.J.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: LD: Cannot add content to ctors section
2020-05-20 9:15 LD: Cannot add content to ctors section Ben Hirschberg
2020-05-20 11:45 ` H.J. Lu
@ 2020-05-21 4:57 ` Alan Modra
2020-05-21 6:12 ` Fangrui Song
1 sibling, 1 reply; 12+ messages in thread
From: Alan Modra @ 2020-05-21 4:57 UTC (permalink / raw)
To: Ben Hirschberg; +Cc: binutils
On Wed, May 20, 2020 at 09:15:42AM +0000, Ben Hirschberg wrote:
> Hi!
>
> I have a setup (Alpine Linux with Go executables) where I cannot rely on contents of ".init_array" to be called, but ".ctors" are called by musl-libc's loader.
>
> I am trying to add my constructors (C or ASM) to the ".ctors" section, but after linking my shared object they seem to be moved to ".init_array" (however in Alpine the ".ctors" section stays in the final image but it is empty)
>
> Why is this happening? Can make my array stay in ".ctors" section?
There is a binutils configure option --disable-initfini-array that may
help in building a linker that should not map .ctors to .init_array.
Whether this all still works is another question.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: LD: Cannot add content to ctors section
2020-05-21 4:57 ` Alan Modra
@ 2020-05-21 6:12 ` Fangrui Song
0 siblings, 0 replies; 12+ messages in thread
From: Fangrui Song @ 2020-05-21 6:12 UTC (permalink / raw)
To: Ben Hirschberg; +Cc: binutils, Alan Modra
On Wed, May 20, 2020 at 9:57 PM Alan Modra via Binutils
<binutils@sourceware.org> wrote:
>
> On Wed, May 20, 2020 at 09:15:42AM +0000, Ben Hirschberg wrote:
> > Hi!
> >
> > I have a setup (Alpine Linux with Go executables) where I cannot rely on contents of ".init_array" to be called, but ".ctors" are called by musl-libc's loader.
> >
> > I am trying to add my constructors (C or ASM) to the ".ctors" section, but after linking my shared object they seem to be moved to ".init_array" (however in Alpine the ".ctors" section stays in the final image but it is empty)
> >
> > Why is this happening? Can make my array stay in ".ctors" section?
>
> There is a binutils configure option --disable-initfini-array that may
> help in building a linker that should not map .ctors to .init_array.
> Whether this all still works is another question.
>
> --
> Alan Modra
> Australia Development Lab, IBM
musl has supported DT_INIT_ARRAY since 2013
https://git.musl-libc.org/cgit/musl/commit/?id=e69ae844dcc978f68761e4bc44fc5543717b9684
Only on arm and aarch64 DT_INIT is disabled.
In gold, the feature is provided by an enabled-by-default option
--ctors-in-init-array
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-05-21 6:12 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-20 9:15 LD: Cannot add content to ctors section Ben Hirschberg
2020-05-20 11:45 ` H.J. Lu
2020-05-20 11:52 ` Ben Hirschberg
2020-05-20 12:11 ` H.J. Lu
2020-05-20 12:50 ` Ben Hirschberg
2020-05-20 13:05 ` H.J. Lu
2020-05-20 13:21 ` Ben Hirschberg
2020-05-20 13:22 ` H.J. Lu
2020-05-20 13:35 ` Ben Hirschberg
2020-05-20 17:00 ` H.J. Lu
2020-05-21 4:57 ` Alan Modra
2020-05-21 6:12 ` Fangrui Song
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).