Re: Generalized init_priority attribute

["Aaron W. LaFramboise" <aaronavay62 at aaronwl dot com>]

Danny Smith wrote:

> Aaron W. LaFramboise wrote:
> 
>>Also, I don't feel very sorry for users who get unfavorable
>>initialization order because they knowingly circumvented the
>>init_priority system with asm().
> 
> How would anyone know that writing 
> 
> _asm_(
>   ".section\t.ctors.foo ,\"w\"\n\t"
>   ".align 4\n\t"
>    ".long\t_bar");
> 
> circumvented gcc's init_priority system.  I found out by accident.

I think this could be avoided somewhat by documenting our expectations
with regards to .ctors and initialization priority somewhere, so as to
form something of an ABI.

Additionally, perhaps inserting some letters in front of the formatted
priority integer to put GCC-emitted constructor pointers before 'most'
other constructs would be appropriate, such that accidents of this sort
would be very unlikely.  This would require the user to form a fairly
perverse section name in order to get their pointers placed earlier than
GCC's.

The nice thing about this is that it allows a normal .c file to
intentionally get its ctors initialized first, if it knows it needs it,
without having to violate interface boundaries any more than necessary.


As a side note, I was always of the understanding that the
crtbegin/crtend system was something of a wart, that a proper system
should not need.  I'm not really sure why I think this.

Also, one reason I'm nervous about crtbegin is that it puts more stuff
into the GNU linker than the MS linker doesn't have, creating one more
reason that GCC-generated code will be incompatible with the MS linker.
 (One day I'd like GCC to work with the MS linker.  Their linker has
features that GNU's doesn't, that are occasionally necessary--and its
probably always going to be this way.)


Please, though, don't interpret anything I'm saying as an objection to
your patches that are ready to apply right now.  We don't need another
collect2 situation. :-)


Aaron W. LaFramboise