This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
Re: [APPROVE?] Fix MIPS and PowerPC with GCC 3.x
- From: Bart Veer <bartv at ecoscentric dot com>
- To: jifl at eCosCentric dot com
- Cc: ecos-patches at sources dot redhat dot com
- Date: Thu, 27 Feb 2003 14:01:55 +0000 (GMT)
- Subject: Re: [APPROVE?] Fix MIPS and PowerPC with GCC 3.x
- References: <3E5DACAB.7050501@eCosCentric.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