Re: [APPROVE?] Fix MIPS and PowerPC with GCC 3.x

[Gary Thomas <gary at mlbassoc dot com>]

On Thu, 2003-02-27 at 07:01, Bart Veer wrote:
> >>>>> "Jifl" == Jonathan Larmour <jifl at eCosCentric dot com> writes:
> 
>     <snip>
>     Jifl> With this, GCC behaves identically in C and C++. However
>     Jifl> this broke GCC 2.x targets. So the attached patch adds a
>     Jifl> simple check to DTRT. And add some documentation to explain
>     Jifl> the obfuscation.
> 
>     Jifl> Checked in to trunk and definitely wants approval for
>     Jifl> branch.
> 
>     Jifl> If anyone has any suggestions on how to resolve this
>     Jifl> compatibility without the munging of kapidata.h I'd be all
>     Jifl> ears!
> 
> I can think of a number of ways of addressing the problem generally,
> but all of them have other issues. The fundamental problem is that we
> should not really be making assumptions about C and C++
> interoperability at the class/structure, and this may haunt us again
> in future.
> 
> 1) make the C structures completely opaque, i.e. just a packed array
>    of the appropriate number of bytes. Of course we now need a way of
>    figuring out what that number of bytes should be. I suspect the
>    best way is to have a custom build step which compiles a special
>    C++ file containing stuff like:
> 
>        int sizeof_thread = sizeof(Cyg_Thread);
> 
>    The resulting assembler would then be processed by a Tcl script
>    which generates an appropriate kapidata.h.
> 
>    Big advantage: the data structures are only defined in one place,
>    the C++ headers, so there is no possibility of mismatches. Also
>    there is no longer any need to update kapidata.h if the C++ classes
>    change, e.g. because we add more configurability.
> 
>    Disadvantages:
>      a) it breaks any existing C code that peeks into kernel data
>         structures. Arguably we can get away with this because we
>         have never documented the contents of these structures.
>      b) the custom build step could be messy, having to cope with
>         assembler files for n different architectures
>      c) the custom build step could be fragile if there are gcc
>         changes which subtly change the format of the generated
>         assembler.
> 
> 2) much more ambitiously, have a custom build step which generates the
>    C data structures based on the results of compiling a suitable C++
>    file. This is probably a non-starter, I suspect it would be much
>    too complicated and hence fragile.
> 
> 3) make the final elements of the C++ classes a union which somehow
>    forces alignment of the class end to the next appropriate alignment
>    boundary, thus preventing the compiler from playing games with
>    packing or padding. This should work but would be very ugly.
> 
> 4) possibly, put a zero length array at the end of each class,
>    effectively preventing the compiler from reusing the spare space.
>    This could have strange side effects.
> 
> 5) try messing about with attributes like packed. However I think that
>    is something we should avoid, new compiler versions could break
>    the code.
> 
> Of these options, I find (1) somewhat attractive because it eliminates
> duplication of data and should prove a long-term fix, but breaking
> existing code may be unacceptable.
> 

I agree that (1) is the way forward.  I've done similar things this way
before and while there is initial pain getting it setup (making it 
automatic, etc), in the end it will always work properly.  I recall
wondering [to myself, many years ago] why it wasn't done that way in the
beginning.

-- 
------------------------------------------------------------
Gary Thomas                 |
MLB Associates              |  Consulting for the
+1 (970) 229-1963           |    Embedded world
http://www.mlbassoc.com/    |
email: <gary at mlbassoc dot com>  |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------