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

[Nick Clifton <nickc at redhat dot com>]

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