On Tue, 30 Nov 2004, Stefan Reinauer wrote:
So you are saying people out there are building LinuxBIOS with non-gnu compilers? I actually doubt that, assuming a lot of objcopy/objdump/ld magic is pretty much gnu specific as well..
no, what i'm saying is that there are people (me, at least) building payloads with non-gnu compilers. If you use gcc magic to fix that struct, and said magic is not available in the other compilers, then the payload will not be able to read the table easily. I've had this very same problem passing structs between Xen and Plan 9; Xen relies on every gcc trick in the book, which is very hard to deal with when you have a non-gcc compiler.
Plus, even if you get all the gcc flags done correctly, we still have the table version problem, as has been shown with the various versions of the SMP tables.
It's been shown in practice that you can avoid these problems by not using a binary table; plan 9 has used strings for 16 years now with no ill effects. I would NOT recommend that V2 use a binary table but there seems to be some resistance to a strings-based table. In any event, V3 will use a string-based interface.
Fixing the issue among all gcc versions while not breaking anything on others. It really sucks that gcc does magic here that makes writing portable code really ugly.
it's only an issue because we're trying to using binary tables in a way that is simply not appropriate for portability. The problem is easily fixed, but there seems to be some resistance to doing this in V2.
ron