grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Eliminate NESTED_ATTR_FUNC


From: Robert Millan
Subject: Re: [RFC] Eliminate NESTED_ATTR_FUNC
Date: Tue, 1 Sep 2009 18:02:40 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Tue, Sep 01, 2009 at 11:43:10PM +0800, Bean wrote:
> On Tue, Sep 1, 2009 at 9:42 PM, Vladimir 'phcoder'
> Serbinenko<address@hidden> wrote:
> > Hello. NESTED_ATTR_FUNC was introduced 6 years ago to workaround a bug
> > in compiler. Now it creates only problems. In particular if they are
> > used wrong it creates a bug of argument passing. Such bugs are
> > difficult to find because it usually results in strange behaviour and
> > in grub-emu NESTED_FUNC_ATTR is exteneded to an empty string so gdb
> > and valgrind can't detect any error. Should we perhaps remove it
> > coupled with adding a requirement for at least gcc 4.2? Can I run
> > s/NESTED_FUNC_ATTR//g; on entire codebase and remove corresponding
> > entry in configure.ac?
> 
> Hi,
> 
> I make an assembly dump of the code generated by gcc-4.2. Apparently,
> the "FIX" is achieved by ignoring the regparm attribute at all.
> __attribute__ ((__regparm__ (3))) doesn't have any effect any more, it
> always pass the parameters on the stack. This defeats the original
> purpose of -mregparm=3, which passes parameters using register and
> therefore reduce module size. In fact, if we are going to use stack,
> we could just remove -mregparm=3 option, this works for all version of
> gcc.

I have the impression that using stack isn't a good idea for GRUB, due to
size and speed improvements, except in cases where we can't avoid it.

If older versions of GCC ignore -mregparm, we need a configure check
(I prefer one that checks for the feature itself, but a version check
is also acceptable IMHO).

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]