linux-kernel - Re: [uml-devel] arch/um/sys-i386/setjmp.S: useless #ifdef

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20060829082641.48020.qmail@web25222.mail.ukl.yahoo.com>
Date:	Tue, 29 Aug 2006 10:26:41 +0200 (CEST)
From:	Paolo Giarrusso <blaisorblade@...oo.it>
To:	Jeff Dike <jdike@...toit.com>
Cc:	user-mode-linux-devel@...ts.sourceforge.net,
	Adrian Bunk <bunk@...sta.de>, linux-kernel@...r.kernel.org
Subject: Re: [uml-devel] arch/um/sys-i386/setjmp.S: useless #ifdef _REGPARM's?

Jeff Dike <jdike@...toit.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 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/