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
Bart Veer wrote:
"Jifl" == Jonathan Larmour <jifl at eCosCentric dot com> writes:
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.
Indeed.
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.
Ah. Yes that particular way wouldn't work, but this alternative might:
Write a C++ program used in a custom build step to generate a header which
#defines all the sizes in bytes instead.
This would be similar to the various hal_mk_defs.c's floating around,
although they requires knowledge of asm syntax. Instead the C++ file can
just generate the header contents directly with #define's and the custom
build step can move it into the install tree. Something similar happens
for the heap magic in the memalloc package (a TCL file doing the
generating that time).
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.
Nah.
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.
Yes it would waste space "unnecessarily". What's more if we had more long
longs floating aroudn in base classes GCC could optimise away a second set
of 8 bytes and we're left where we are again - it isn't long term.
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.
Yep, thought of that - it wouldn't be legal as a base class though.
5) try messing about with attributes like packed. However I think that
is something we should avoid, new compiler versions could break
the code.
Already considered that. It can also be quite inefficient indeed.
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.
Don't know. Maybe the maintenance overhead for kapidata.h isn't worth it?
But I think there's mileage in my modified suggestion 1) above.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine