Re: [patch, rfc] Semantics of attribute (aligned), misscompilation of crtstuff

[Mark Mitchell <mark at codesourcery dot com>]

Zdenek Dvorak wrote:

>> I think it would be a better use of time to fix a serious bug in the
>> compiler.  But, I'm happy to try to explain the suggestion in more
>> detail if you're excited about cleaning this up.
> 
> yes, please.  

At present, there are three possible solutions discussed.

We could adopt Daniel's suggestion: support both packed and aligned
attributes on variables, to indicate a precise alignment, and then add
"packed" to the declaration there, indicating that the alignment of this
variable should not be increased by any optimization pass.  This
solution is nice because it might be useful in other circumstances
besides crtstuff.c.

Another solution would be a #pragma.  Concretely, crtstuff.c would do:

  #pragma GCC begin_ctor_array
  extern func_ptr *__CTOR_LIST__;

in lieu of the section that presently does:

#ifdef CTOR_LIST_BEGIN
...
#elif
...
#endif

Then, the compiler would incorporate the logic presently in crtstuff.c.
 In particular, on an ELF system, it would switch to the .ctors section,
and emit a label named __CTOR_LIST__.  Note that this would probably
simplify the back ends a bit; for example, we could probably get rid of
CTORS_SECTION_ASM_OP, since we just use the normal machinery we have for
switching to a particular section.  To the extent a backend still needs
custom code, it would be custom code written in terms of GCC's machinery
for switching sections and emitting labels, not in terms of assembly
code directly.  We would have similar pragmas for the end of the ctor
array, and the beginning and end of the dtor array.  This solution is
nice because it would clean up crtstuff.c, which is a tangled mess of
assembly-in-GNU-C.

The other option I suggested would be to have the backends do emission
of assembly code directly, again eliminating the array declaration.  So,
instead of the:

#ifdef CTOR_LIST_BEGIN
...
#elif
...
#endif

section, we could just do:

CTOR_LIST_BEGIN;
extern func_ptr *__CTOR_LIST__;

and the back end would define CTOR_LIST_BEGIN to something like:

asm("\t.ctors\n"
    "\t__CTOR_LIST__:");

In both cases, we remove the data declaration from GCC's purview so that
it cannot insert padding we don't want.

> I probably consider having a valid code in the compiler
> much more important than you -- if we do not have a valid code in the
> compiler, how can we ask other people to write a valid code?  How would
> you answer query of someone who copied this trick to his code and found
> out that it does not work for him -- we always knew that this is an ugly
> hack and that it cannot work, but we were too lazy to fix it?

There's a ton of invalid code out there being compiled with GCC all the
time.  When CodeSourcery customers ask us how to make invalid code work,
we tell them how to fix the code -- and about options they can use to
work around the problem.  That's why we have -fpermissive,
-fno-strict-aliasing, etc. in the compiler.  It's not always realistic
for them to fix their code to be valid according to the standard.  I
don't think it's such a horrid thing if very low-level parts of our
run-time libraries are invalid C; in most compilers I've seen, those
things are just written as assembly code.

But, of course, if we can fix our code, that's even better.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713