arch/um/sys-i386/setjmp.S: useless #ifdef _REGPARM's?

arch/um/sys-i386/setjmp.S: useless #ifdef _REGPARM's?

[Adrian Bunk]

arch/um/sys-i386/setjmp.S contains two #ifdef _REGPARM's.

Even if regparm was used in i386 uml (which isn't currently done (why?)),
I don't see _REGPARM being defined anywhere.

Is this a bug waiting for happening when regparm will be used on uml or 
do I miss anything?

cu
Adrian

-- 

    Gentoo kernels are 42 times more popular than SUSE kernels among
    KLive users  (a service by SUSE contractor Andrea Arcangeli that
    gathers data about kernels from many users worldwide).

       There are three kinds of lies: Lies, Damn Lies, and Statistics.
                                                    Benjamin Disraeli

Re: [uml-devel] arch/um/sys-i386/setjmp.S: useless #ifdef _REGPARM's?

[Jeff Dike]

On Mon, Aug 21, 2006 at 11:56:41PM +0200, Adrian Bunk wrote:
> arch/um/sys-i386/setjmp.S contains two #ifdef _REGPARM's.
> 
> Even if regparm was used in i386 uml (which isn't currently done (why?)),
> I don't see _REGPARM being defined anywhere.

setjmp.S was stolen from klibc, and I'd just as soon leave it alone and
not try to customize it for UML.  That file will disappear if/when klibc 
is in mainline, and I can just pull it in from usr.

In general, there's no reason that regparam can't be used for UML.  However,
in the past (I don't know if it's still a problem) gcc miscompiled regparam
code in the presence of -pg.

As for why it's not, I don't see any occurences of regparam in include/linux
or include/asm-i386 either.

> Is this a bug waiting for happening when regparm will be used on uml or 
> do I miss anything?

Probably not.

				Jeff

Re: [uml-devel] arch/um/sys-i386/setjmp.S: useless #ifdef _REGPARM's?

[Adrian Bunk]

On Mon, Aug 21, 2006 at 10:20:12PM -0400, Jeff Dike wrote:
> On Mon, Aug 21, 2006 at 11:56:41PM +0200, Adrian Bunk wrote:
> > arch/um/sys-i386/setjmp.S contains two #ifdef _REGPARM's.
> > 
> > Even if regparm was used in i386 uml (which isn't currently done (why?)),
> > I don't see _REGPARM being defined anywhere.
> 
> setjmp.S was stolen from klibc, and I'd just as soon leave it alone and
> not try to customize it for UML.  That file will disappear if/when klibc 
> is in mainline, and I can just pull it in from usr.

Ah, klibc defines _REGPARM if required.

> In general, there's no reason that regparam can't be used for UML.  However,
> in the past (I don't know if it's still a problem) gcc miscompiled regparam
> code in the presence of -pg.

I didn't find a corresponding open bug in the gcc Bugzilla.

Can someone verify whether it's still present, and if yes, open a gcc 
bug?

> As for why it's not, I don't see any occurences of regparam in include/linux
> or include/asm-i386 either.

It's set globally in arch/i386/Makefile:
  cflags-$(CONFIG_REGPARM) += -mregparm=3

That's not pulled by UML, but if there are no outstanding problems with 
regparm, we could both enable it uncomditionally on i386 and enable it
on UML/i386.

> > Is this a bug waiting for happening when regparm will be used on uml or 
> > do I miss anything?
> 
> Probably not.
> 
> 				Jeff

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [uml-devel] arch/um/sys-i386/setjmp.S: useless #ifdef _REGPARM's?

[Jeff Dike]

On Tue, Aug 22, 2006 at 06:07:41PM +0200, Adrian Bunk wrote:
> I didn't find a corresponding open bug in the gcc Bugzilla.
> 
> Can someone verify whether it's still present, and if yes, open a gcc 
> bug?

Yup, it's easy enough to check.

> It's set globally in arch/i386/Makefile:
>   cflags-$(CONFIG_REGPARM) += -mregparm=3

IIRC, there used to be functions explicitly declared as __regparam or
something, and that's what I was grepping for.  Does this turn every
function with three or fewer parameters into a regparam function?

> That's not pulled by UML, but if there are no outstanding problems with 
> regparm, we could both enable it uncomditionally on i386 and enable it
> on UML/i386.

That shouldn't be a problem.

				Jeff

Re: [uml-devel] arch/um/sys-i386/setjmp.S: useless #ifdef _REGPARM's?

[Adrian Bunk]

On Tue, Aug 22, 2006 at 01:42:33PM -0400, Jeff Dike wrote:
> On Tue, Aug 22, 2006 at 06:07:41PM +0200, Adrian Bunk wrote:
> > I didn't find a corresponding open bug in the gcc Bugzilla.
> > 
> > Can someone verify whether it's still present, and if yes, open a gcc 
> > bug?
> 
> Yup, it's easy enough to check.

Thanks.

> > It's set globally in arch/i386/Makefile:
> >   cflags-$(CONFIG_REGPARM) += -mregparm=3
> 
> IIRC, there used to be functions explicitly declared as __regparam or
> something, and that's what I was grepping for.  Does this turn every
> function with three or fewer parameters into a regparam function?
>...

With -mregparm=3, the first up to three parameters that aren't bigger 
than an integer are passed in registers instead of on the stack.

> 				Jeff

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [uml-devel] arch/um/sys-i386/setjmp.S: useless #ifdef _REGPARM's?

[Blaisorblade]

On Monday 21 August 2006 23:56, Adrian Bunk wrote:
> arch/um/sys-i386/setjmp.S contains two #ifdef _REGPARM's.
>
> Even if regparm was used in i386 uml (which isn't currently done (why?)),
> I don't see _REGPARM being defined anywhere.
>
> Is this a bug waiting for happening when regparm will be used on uml or
> do I miss anything?
Can anybody explain me how can we use REGPARM if we have to link with host 
glibc?
If we are going to use klibc instead of glibc that's ok (and this is not the 
case I'm talking about), but I do not know that plan (and nobody discussed 
the implications).
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 

Re: [uml-devel] arch/um/sys-i386/setjmp.S: useless #ifdef _REGPARM's?

[Jeff Dike]

On Sat, Aug 26, 2006 at 12:56:36PM +0200, Blaisorblade wrote:
> Can anybody explain me how can we use REGPARM if we have to link with host 
> glibc?

Umm, yeah, good point.  This regparam behavior is different from the old
behavior, where regparam functions had to be declared as such.

However, this is a potential problem with all regparam users, who all
presumably use libc, so I'd imagine it works somehow.

> If we are going to use klibc instead of glibc that's ok (and this is not the 
> case I'm talking about), but I do not know that plan (and nobody discussed 
> the implications).

I've been idly considering that, but it's no more than idle consideration
right now.

				Jeff

Re: [uml-devel] arch/um/sys-i386/setjmp.S: useless #ifdef _REGPARM's?

[Paolo Giarrusso]

Jeff Dike <jdike@addtoit.com> ha scritto: 

> On Sat, Aug 26, 2006 at 12:56:36PM +0200, Blaisorblade wrote:
> > Can anybody explain me how can we use REGPARM if we have to link
> with host 
> > glibc?

> Umm, yeah, good point.  This regparam behavior is different from
> the old
> behavior, where regparam functions had to be declared as such.

And which can still be enabled - I think fastcall is for this, and it
is still useful.

However more useful is to move many wrappers where this is possible
to headers (for instance the ones calling just
CHOOSE_MODE($me_tt,$me_skas) - moving them to headers is always
possible and saves a call).

> However, this is a potential problem with all regparam users, who
> all
> presumably use libc, so I'd imagine it works somehow.

For my knowledge, the only user is the non-UML Linux kernel, which
doesn't use libc :-).

And if you want to mix regparm and not regparm calls, you end up
marking it at a prototype level (i.e. with the old approach); GCC
could be smarter and allow specifying it at a per-header or per
header-folder level, but I do not think it does.

> > If we are going to use klibc instead of glibc that's ok (and this
> is not the 
> > case I'm talking about), but I do not know that plan (and nobody
> discussed 
> > the implications).

> I've been idly considering that, but it's no more than idle
> consideration
> right now.

Fine... it is actually a good idea for some points (we currently
refrain from using certain things, such as futexes, because our
tricks could conflict with glibc tricks which we don't know - with
klibc it would be different).
We'll see.

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com