On Fri, 2008-04-25 at 17:37 +0300, Marko Kreen wrote:
> > I mean, they are both 0 unless -m32 or -m64 is specified.
>
> No, see other sections - they assume one of them is set unless overrided.
If you are fixing a bug, you cannot rely on the code being correct. Try
printing those variables:
printf("m32=%d, m64=%d\n", $m32, $m64);
It will be two zeroes.
> > > Or do you mean I cannot assume one of them as set, unless
> > > overrided on command line? But other sections (spact, i86, ppc)
> > > do exactly that?
> >
> > You cannot assume either of them to be 1 until cgcc is fixed.
>
> But how should the fix look like if you don't like mine?
Well, it looks like cgcc is seriously broken. In particular, it would
define x86_64 even if -m32 is specified, but it should define i386
instead.
Also, cgcc looks at uname output to determine the target CPU. That
would default to 64 bit if a 32-bit system runs on a 64-bit kernel. I
think cgcc should be running gcc instead to dump the machine settings.
I realize that it might be slower, but correctness is important here.
On the other hand, I'm not sure if we can rely on having gcc installed.
I would probably introduce a variable that would hold the memory model.
It could be ILP32 or LP64, but we could eventually support LLP64 (win64)
and even LP32 (win16). It could be determined based on -m32/-m64
switches and uname output, but be could switch to "gcc -dumpmachine"
later.
The architecture would be adjusted based on the selected memory model.
And then it would be passed to add_specs().
--
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
