Re: [PATCH] Make `obsolete params' work correctly if MODULE_SYMBOL_PRE

Re: [PATCH] Make `obsolete params' work correctly if MODULE_SYMBOL_PRE

[Kai Henningsen]

rusty@rustcorp.com.au (Rusty Russell)  wrote on 11.01.03 in <20030111224007$7807@gated-at.bofh.it>:

> In message <Pine.LNX.4.44.0301102134150.9532-100000@home.transmeta.com> you
> wri te:
> >
> > On Sat, 11 Jan 2003, Rusty Russell wrote:
> > >
> > > Just in case someone names a variable over 2000 chars, and uses it as
> > > an old-style module parameter?
> >
> > No. Just because variable-sized arrays aren't C, and generate crappy code.
> >
> > >  	for (i = 0; i < num; i++) {
> > > +		char sym_name[strlen(obsparm[i].name)
> > > +			     + sizeof(MODULE_SYMBOL_PREFIX)];
> >
> > It's still there.
>
> OK, *please* explain to me in little words so I can understand.

Do "char sym_name[CONSTANT];". What's so hard to understand about that?

> Variable-sized arrays are C, as of C99.  They've been a GNU extension
> forever.

Actually, the gcc thing and the C99 thing are significantly different, and  
neither is a sub- or superset of the other. In fact, gcc's C99-conformance  
page (http://gcc.gnu.org/c99status.html) still lists VLAs as "broken".

See here for at least some explanation:
        http://gcc.gnu.org/ml/gcc/2002-10/msg00470.html

> While gcc 2.95.4 generates fairly horrible code, gcc 3.0 does better
> (the two compilers I have on my laptop).
>
> Both generate correct code.

For the GNU extension, maybe.

MfG Kai

Re: [PATCH] Make `obsolete params' work correctly if MODULE_SYMBOL_PRE

[Richard B. Johnson]

On 13 Jan 2003, Kai Henningsen wrote:

> rusty@rustcorp.com.au (Rusty Russell)  wrote on 11.01.03 in <20030111224007$7807@gated-at.bofh.it>:
> 
> > In message <Pine.LNX.4.44.0301102134150.9532-100000@home.transmeta.com> you
> > wri te:
> > >
> > > On Sat, 11 Jan 2003, Rusty Russell wrote:
> > > >
> > > > Just in case someone names a variable over 2000 chars, and uses it as
> > > > an old-style module parameter?
> > >
> > > No. Just because variable-sized arrays aren't C, and generate crappy code.
> > >
> > > >  	for (i = 0; i < num; i++) {
> > > > +		char sym_name[strlen(obsparm[i].name)
> > > > +			     + sizeof(MODULE_SYMBOL_PREFIX)];
> > >
> > > It's still there.
> >
> > OK, *please* explain to me in little words so I can understand.
> 
> Do "char sym_name[CONSTANT];". What's so hard to understand about that?
> 
> > Variable-sized arrays are C, as of C99.  They've been a GNU extension
> > forever.
> 
> Actually, the gcc thing and the C99 thing are significantly different, and  
> neither is a sub- or superset of the other. In fact, gcc's C99-conformance  
> page (http://gcc.gnu.org/c99status.html) still lists VLAs as "broken".
> 
> See here for at least some explanation:
>         http://gcc.gnu.org/ml/gcc/2002-10/msg00470.html
> 
> > While gcc 2.95.4 generates fairly horrible code, gcc 3.0 does better
> > (the two compilers I have on my laptop).
> >
> > Both generate correct code.
> 
> For the GNU extension, maybe.
> 
> MfG Kai

In principle, the idea of variable-length arrays should cause
the compiler to generate very reasonable code because the
length is only a value to subtract from ESP.

void foo(int len)
{
   char use[0x100];
   char bar[len];
}

In the case of 'use', the compiler subtracts (0x100 * sizeof(char))
from the current stack value and uses that as the location for 'use'.
In the case of 'bar' the compiler subtracts (len * sizeof(char))
from the current stack value and uses that as the location for 'bar'.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.

Re: [PATCH] Make `obsolete params' work correctly if MODULE_SYMBOL_PRE

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 800 bytes --]

On Mon, 13 Jan 2003 15:28:45 EST, "Richard B. Johnson" said:

> void foo(int len)
> {
>    char use[0x100];
>    char bar[len];
> }
> 
> In the case of 'use', the compiler subtracts (0x100 * sizeof(char))
> from the current stack value and uses that as the location for 'use'.
> In the case of 'bar' the compiler subtracts (len * sizeof(char))
> from the current stack value and uses that as the location for 'bar'.

One or the other of these is missing a -0x100 for the location...

void foo (int len1, unsigned int len2)
{
  char bar[0x100];
  char baz[len1];
  char quux[len2];
  char moby[8];
}

And moby[6] is *where*? ;)  Bonus points for getting this right if
compiled with -fvomit-stack-pointer. <evil grin> ;)
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH] Make `obsolete params' work correctly if MODULE_SYMBOL_PRE

[Richard B. Johnson]

On Mon, 13 Jan 2003 Valdis.Kletnieks@vt.edu wrote:

> On Mon, 13 Jan 2003 15:28:45 EST, "Richard B. Johnson" said:
> 
> > void foo(int len)
> > {
> >    char use[0x100];
> >    char bar[len];
> > }
> > 
> > In the case of 'use', the compiler subtracts (0x100 * sizeof(char))
> > from the current stack value and uses that as the location for 'use'.
> > In the case of 'bar' the compiler subtracts (len * sizeof(char))
> > from the current stack value and uses that as the location for 'bar'.
> 
> One or the other of these is missing a -0x100 for the location...
> 
> void foo (int len1, unsigned int len2)
> {
>   char bar[0x100];
>   char baz[len1];
>   char quux[len2];
>   char moby[8];
> }
> 
> And moby[6] is *where*? ;)  Bonus points for getting this right if
> compiled with -fvomit-stack-pointer. <evil grin> ;)
> -- 

Trivial. The constant stuff gets allocated first, then the dynamic.
You can write the code in any order you want, but the code generation
is as though you did:
	char bar [0x100];
        char moby[8];
Also, vomit-stack-pointer is "f(v)omit-frame-pointer". It works
the same. No problem except when trying to find local variables
in the debugger (known -g implimentation "feature"). The frame
pointer is BP. The stack is never omitted. You can save a few
instructions if you don't use it.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.