Re: Fwd: [PATCH] COFF Compliant .ctors and .dtors sections

[Martell Malone <martellmalone at gmail dot com>]

Hey Nick,

First I would like to thank you for the detailed reply.
I really appreciate it.

I wanted to follow up with a question and a small nit on the reply.

> In fact to be clearer - and more consistent - I would suggest changing
> the names of the start and end constructor sections to be something like:
> .ctors$start and .ctors$end.

LLD and LINK.exe do not have any notion of a linker script and will
organise the section in the following order.
.ctors
.ctors.AAAAA
.ctors.zzz

Where it will do .ctors then alphabetically ordered by uppercase then lowercase.
The reason I was using .ctors$zzz is the get those linkers to place it
at the end.
Technically someone could add extra z's which would then never get
called so I am relying on people not doing something so ridiculous.

 With that in mind would the following be acceptable to you.

${CONSTRUCTING+
    PROVIDE(__CTOR_LIST__ = .);
    PROVIDE(___CTOR_LIST__ = .);
    LONG(-1);
    KEEP (*(.ctors));
    KEEP (*(.ctor));
    KEEP (*(SORT_BY_NAME(.ctors.*)));
    LONG(0);
  }

For my question I also wanted to ask while I we are in discussion on
the linker scripts how would I make an alias name to __image_base__ to
__ImageBase?
I am unfamiliar with linker script terminology for doing this.
The line where __image_base__ is defined is at the beginning of the
.text sections.
I believe this is also the entry point.

Kind Regards
Martell

On Tue, Aug 8, 2017 at 10:26 AM, Nick Clifton <nickc@redhat.com> wrote:
> Hi Martell,
>
>> I would like to propose the following patch to go with a pair that is
>> on the mingw-w64 mailing list which implements this on the crt end.
>
> It seems to me that there might be a few problems with this patch...
>
>> diff --git a/ld/scripttempl/pe.sc b/ld/scripttempl/pe.sc
>
> The pe.sc and pep.sc script templates are used by more than just the mingw64
> target.  So the changes that you make should really be guarded by a test of
> some kind, or else made universal.
>
> The changes also rely upon the crt files being updated, but there is no
> check to make sure that the new versions are being used in the link...
>
> I may however have a solution to both of these problems - see below:
>
>
>> +    ${CONSTRUCTING+*(SORT(.ctors.*))}
>
> This excludes the .ctors section from crtexe.o!  You probably meant:
>
>        ${CONSTRUCTING+*(.ctors);*(SORT(.ctors.*))}
>
>
>> +__attribute__ (( __section__ (".ctors$zzz"), __used__ ,
>> aligned(sizeof(void *)))) const void * __CTOR_END__ = (void *) 0;
>
> This will fail because the .ctors$ prefix is not included in the section
> matching criteria either.  So the script probably ought to contain:
>
>    ${CONSTRUCTING+*(.ctors);*(SORT(.ctors.*));*(.ctors$zzz)}
>
> In fact to be clearer - and more consistent - I would suggest changing
> the names of the start and end constructor sections to be something like:
> .ctors$start and .ctors$end.
>
> Additionally you are dropping the KEEP directives - which are important,
> and ignoring the .ctor section, which may not be needed nowadays, I am
> not sure, but probably ought to still be included just to be safe.  Plus
> the documentation recommends using SORT_BY_NAME rather than SORT, so that
> it is clear how the sections are being arranged.  All of which leads to:
>
>   ${CONSTRUCTING+
>     KEEP (*(.ctors$start))
>     KEEP (*(.ctors));
>     KEEP (*(.ctor));
>     KEEP (*(SORT_BY_NAME(.ctors.*)))
>     KEEP (*(.ctors$end))
>    }
>
> Next - you could simplify the patch by placing the definitions of
> __CTOR_xxx symbols inside a PROVIDE statement, so that they are only
> defined if not provided by the crt files.  Plus - here is the clever
> bit - you could arrange for the provided symbol to appear just before
> the -1 sentinel and just after the 0 sentinel, like this:
>
>   ${CONSTRUCTING+
>     PROVIDE(__CTOR_LIST = .);
>     PROVIDE(___CTOR_LIST = .);
>     LONG(-1);
>     KEEP (*(.ctors$start));
>     KEEP (*(.ctors));
>     KEEP (*(.ctor));
>     KEEP (*(SORT_BY_NAME(.ctors.*)));
>     KEEP (*(.ctors$end));
>     LONG(0);
>   }
>
> So this version should be compatible with both the old crt files and
> your proposed new one.  If the new file is used then it will define its
> own version of __CTOR_LIST__, which will start at the beginning of the
> .ctors$start section, which is *after* the LONG(-1).  So the loader will
> not be confused.  Plus since your crt file defines __CTOR_END__ as part
> of .ctors$end the loader will never see the final LONG(0), and again will
> not be confused.
>
> [All of the above also applies to the destructor sections as well...]
>
> Of course I have not actually tested the above suggestion, but I think that
> it should work.
>
> Cheers
>   Nick