Re: Unexpected behavior regarding linking sections

[Michael Matz <matz at suse dot de>]

Hi,

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)

> __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).

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__ .

So, I'd do some tracing.  Use ld -M and -y <some-symbol> for some 
insights.  Otherwise provide full linkable inputs to some bugzilla report.


Ciao,
Michael.