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>

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

    Jifl> Ah. Yes that particular way wouldn't work, but this
    Jifl> alternative might: Write a C++ program used in a custom
    Jifl> build step to generate a header which #defines all the sizes
    Jifl> in bytes instead.

    Jifl> This would be similar to the various hal_mk_defs.c's
    Jifl> floating around, although they requires knowledge of asm
    Jifl> syntax. Instead the C++ file can just generate the header
    Jifl> contents directly with #define's and the custom build step
    Jifl> can move it into the install tree. Something similar happens
    Jifl> for the heap magic in the memalloc package (a TCL file doing
    Jifl> the generating that time).

I don't see how your approach is going to work. We need to know how
the target g++ messes about with its classes, not the host g++. Since
we cannot execute a feature test program, the way to do this is to
generate some assembler with the target g++ and analyse that, e.g.
with a Tcl script.

Bart