This is the mail archive of the
mailing list for the glibc project.
Re: Support bits/syscall.h build for triarch systems
> This patch implements the general approach along the lines you describe.
> The generated header looks right for x86_64 and (with an associated ports
> patch that eliminates the custom makefile rule, and the custom MIPS
> configure code to deal with preprocessing asm/unistd.h, and the custom
> MIPS version of sys/syscall.h) for MIPS. On x86_64 I've also verified
> that the glibc build completes OK; the testsuite runs OK up until a
> failure of timezone/test-tz that probably results from the issue for which
> a patch was posted in
> <http://sourceware.org/ml/libc-alpha/2011-12/msg00054.html> (I have not
> investigated the failure or studied that patch, but this seems the most
> likely cause of that failure).
I think the most useful sort of anal testing would be just to write
up a file that enumerates all the conceivable SYS_* macros, as in:
Then run that through cpp (and perhaps sed to canonicalize the whitespace)
and compare the results from the old and new files in each -mfoo state on
each machine that's affected. I won't insist that you do something like
that now, but if it turns out your code produces headers that have
different effective results in some case, I'll pretend I had insisted.
> (This patch doesn't keep the optimization in the biarch code of emitting
> most definitions only once and only conditioning individual definitions
> that are only present on one architecture variant; it simply conditions
> the full set of syscalls for each architecture variant, which is certainly
> simpler to implement and reduces the risk of some bugs only affecting a
> subset of the uniarch/biarch/triarch cases.)
I tend to think it would be better to preserve the old property and have a
smaller output file. But I'm not going to insist on that.
> +syscall-list-default-condition := 1
I know it's a trifling matter, but a scenario that produces "#if 1"
is something I just cannot abide. Make the special case to avoid it as
clean as you can see how to do, but please do something.
If you've done that clean-up and tested enough that you'd testify to its
correctness, then go ahead and commit it.