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

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "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.

Bart