This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 
> <> (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:

	#include <sys/syscall.h>

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]