public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Andi Kleen <ak@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [klibc 37/43] x86_64 support for klibc
Date: Tue, 27 Jun 2006 08:01:24 -0700	[thread overview]
Message-ID: <44A14844.3010009@zytor.com> (raw)
In-Reply-To: <p73zmfzt2hx.fsf@verdi.suse.de>

Andi Kleen wrote:
> "H. Peter Anvin" <hpa@zytor.com> 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

  reply	other threads:[~2006-06-27 15:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-26  0:58 [klibc 37/43] x86_64 support for klibc H. Peter Anvin
2006-06-27  8:40 ` Andi Kleen
2006-06-27 15:01   ` H. Peter Anvin [this message]
2006-06-27 15:49     ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44A14844.3010009@zytor.com \
    --to=hpa@zytor.com \
    --cc=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox