This is the mail archive of the libc-alpha@sources.redhat.com 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: PATCH: Re: Inefficient ia64 system call implementation in glibc


On Wed, Sep 24, 2003 at 10:36:48PM +0200, Andreas Schwab wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
> 
> > On Wed, Sep 24, 2003 at 10:36:21AM +0200, Andreas Schwab wrote:
> >> "H. J. Lu" <hjl@lucon.org> writes:
> >> 
> >> > On Mon, Sep 22, 2003 at 04:21:23PM -0700, Richard Henderson wrote:
> >> >> On Mon, Sep 22, 2003 at 12:39:18PM -0700, H. J. Lu wrote:
> >> >> > Can I get char * from char [300]?
> >> >> 
> >> >> x+0 would work in this case; I'd guess it'd work for most of the
> >> >> cases that syscalls need to handle.
> >> >> 
> >> >
> >> > This patch works for me.
> >> >
> >> >
> >> > H.J.
> >> > ---
> >> > 2003-09-22  H.J. Lu  <hongjiu.lu@intel.com>
> >> >
> >> > 	* sysdeps/unix/sysv/linux/ia64/sysdep.h (LOAD_ARGS_1): Use
> >> > 	__typeof ((outX) + 0) instead of long.
> >> 
> >> Hopefully we don't have any occurences of LOAD_ARGS_n(...,0,..) where the
> >> kernel expects long.
> >> 
> >
> > I don't think it will be the problem. Compiler will do
> >
> > 	addl outN = constant, r0
> >
> > to pass a constant to the function, regardless what the type is. Am I
> > correct?
> 
> It doesn't have to be a constant, it can be an arbitrary expression of the
> wrong (narrower) type.
> 

Those macros are internal to libc. We can fix all those wrong types
if there are any. My initial test shows no problem. I will install
it on my IPF machine to give it a try.


H.J.


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