Re: [klibc 37/43] x86_64 support for klibc

[H. Peter Anvin]

Andi Kleen wrote:
> "H. Peter Anvin" <hpa@xxxxxxxxx> writes:
> > +
> > +#include <asm/signal.h>
> > +/* The x86-64 headers defines NSIG 32, but it's actually 64 */
> > +#undef  _NSIG
> > +#undef  NSIG
> > +#define _NSIG 64
> > +#define NSIG  _NSIG
>
> If it's really wrong it should be fixed, not workarounded.

It is wrong... include/asm-x86_64/signal.h has cribbed a bit too much 
from i386:

ifdef __KERNEL__
/* Most things should be clean enough to redefine this at will, if care
   is taken to make libc match.  */

#define _NSIG           64
#define _NSIG_BPW       64
#define _NSIG_WORDS     (_NSIG / _NSIG_BPW)

typedef unsigned long old_sigset_t;             /* at least 32 bits */

typedef struct {
        unsigned long sig[_NSIG_WORDS];
} sigset_t;


struct pt_regs;
asmlinkage int do_signal(struct pt_regs *regs, sigset_t *oldset);


#else
/* Here we must cater to libcs that poke about in kernel headers.  */

#define NSIG            32
typedef unsigned long sigset_t;

#endif /* __KERNEL__ */
#endif


I can't remove the workaround just yet, since I have active users of the 
out-of-tree version.  However, I will send you a patch for 
include/asm-x86_64/signal.h.

> > +
> > +/* The x86-64 syscall headers are needlessly inefficient */
> > +
> > +#undef _syscall0
> > +#undef _syscall1
> > +#undef _syscall2
> > +#undef _syscall3
> > +#undef _syscall4
> > +#undef _syscall5
> > +#undef _syscall6
>
> What do you mean with that?

At one point klibc was using the _syscall() macros, and I observed that 
the x86-64 ones generated extra instructions because of the "movq"s that 
were hard-coded in the patterns (using register variables, one can make 
gcc do any moves that may or may not be necessary.)

However, klibc no longer uses these except on ia64, so I removed 
<klibc/archsys.h> for all other architectures from the tree last night.

	-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/