This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Unexpected behavior regarding linking sections
> On Tue, 11 Dec 2018, Felix von Leitner wrote:
> > .section .ctors,"aw"
> > .global __CTOR_LIST__
> > __CTOR_LIST__:
> >
> > .section .dtors,"aw"
> > .global __DTOR_LIST__
> > __DTOR_LIST__:
> >
> > Then, after all the other code, I do this:
> >
> > .section .ctors,"aw"
> > .global __CTOR_END__
> > __CTOR_END__:
> >
> > .section .dtors,"aw"
> > .global __DTOR_END__
> > __DTOR_END__:
> So the above is in a separate .o file you put after all other .o file in
> the link editing process? (If not, that's a problem)
Oh yes, sorry, that was not as clear as I thought it would be.
The first one is an .o that is the first in the link order.
The second one is an .o that is the last in the link order.
> > __CTOR_LIST__ is 0x404fe0
> > __DTOR_LIST__ is 0x404ff0
> >
> > __CTOR_END__ == __DTOR_END__ == 0x405000
> >
> > Uh ... wat? Why is __DTOR_END__ not 0x404ff0? Is this a bug in ld or am
> > I missing something? I'm using gcc 8.2 and binutils 2.31.51.20180823.
> Are you using your own linker script or is ld using one of it's built-in
> ones? If the latter: some of them provide their own __CTOR_END__ symbols,
> which should not be, but might be a problem (check by renaming your
> variants into something unsuspecting).
Nope, I'm using all the stock stuff from gcc and binutils.
Here is the build command line:
gcc -nostdlib -static -L/opt/diet/lib-x86_64 /opt/diet/lib-x86_64/start.o -o t /tmp/x.c -isystem /opt/diet/include -D__dietlibc__ /opt/diet/lib-x86_64/libc.a -lgcc /opt/diet/lib-x86_64/crtend.o
start.o contains __CTOR_LIST__ and __DTOR_LIST__ and crtend.o contains
__CTOR_END__ and __DTOR_END__.
> Otherwise I don't immediate see why the above shouldn't work, in
> particular how __CTOR_END__ could ever be == __DTOR_END__ if .ctors and
> .dtors aren't empty, which they clearly aren't given that e.g.
> __DTOR_END__ != __DTOR_LIST__ and __CTOR_LIST__ != __DTOR_LIST__ .
Exactly, hence my confusion.
I don't quite understand your comment above though. If the linker
provides its own __CTOR_END__, then that should be OK, too, shouldn't
it?
I have uploaded the linkable input to
https://ptrace.fefe.de/ld-testcase.tar.gz
I am not sure how to debug this, to be honest.
Felix