Hi,
I notice that module.h contains stuff like:
#define MODULE_GENERIC_TABLE(gtype,name) \
extern const struct gtype##_id __mod_##gtype##_table \
__attribute__ ((unused, alias(__stringify(name))))
and even:
#define __MODULE_INFO(tag, name, info) \
static const char __module_cat(name,__LINE__)[] \
__attribute_used__ \
__attribute__((section(".modinfo"),unused)) = __stringify(tag) "=" info
My understanding is that we shouldn't be using __attribute__((unused))
in either of these - can someone confirm.
The second one looks fairly dodgy since we're telling a compiler that
it's both used and unused. That sounds a bit like a HHGTTG puzzle (you
have tea and no tea.)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Thu, Oct 14, 2004 at 11:04:56PM +0100, David Woodhouse wrote:
> On Thu, 2004-10-14 at 22:02 +0100, Russell King wrote:
> > Hi,
> >
> > I notice that module.h contains stuff like:
> >
> > #define MODULE_GENERIC_TABLE(gtype,name) \
> > extern const struct gtype##_id __mod_##gtype##_table \
> > __attribute__ ((unused, alias(__stringify(name))))
> >
> > and even:
> >
> > #define __MODULE_INFO(tag, name, info) \
> > static const char __module_cat(name,__LINE__)[] \
> > __attribute_used__ \
> > __attribute__((section(".modinfo"),unused)) = __stringify(tag) "=" info
> >
> > My understanding is that we shouldn't be using __attribute__((unused))
> > in either of these - can someone confirm.
>
> Since the structure in question isn't explicitly referenced from
> elsewhere, the compiler may feel free to omit it. Since we want the
> compiler to emit it, not omit it, we use "unused" to say "yes, I know it
> looks unused; please emit it anyway". Later compilers use "used" to say
> "I use it really; please emit it anyway", meaning much the same thing.
It's the "later compilers" which I'm worried about here - I think they
defined "unused" to mean "this really really isn't used and you can
discard it". Hence my concern with the above.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Thu, 14 Oct 2004, Russell King wrote:
> It's the "later compilers" which I'm worried about here - I think they
> defined "unused" to mean "this really really isn't used and you can
> discard it". Hence my concern with the above.
Your concern is valid. Much enough it's been already fixed in 2.4.27, so
I suppose 2.6 deserves the fix, too.
Maciej
On Thu, 2004-10-14 at 22:02 +0100, Russell King wrote:
> Hi,
>
> I notice that module.h contains stuff like:
>
> #define MODULE_GENERIC_TABLE(gtype,name) \
> extern const struct gtype##_id __mod_##gtype##_table \
> __attribute__ ((unused, alias(__stringify(name))))
>
> and even:
>
> #define __MODULE_INFO(tag, name, info) \
> static const char __module_cat(name,__LINE__)[] \
> __attribute_used__ \
> __attribute__((section(".modinfo"),unused)) = __stringify(tag) "=" info
>
> My understanding is that we shouldn't be using __attribute__((unused))
> in either of these - can someone confirm.
Since the structure in question isn't explicitly referenced from
elsewhere, the compiler may feel free to omit it. Since we want the
compiler to emit it, not omit it, we use "unused" to say "yes, I know it
looks unused; please emit it anyway". Later compilers use "used" to say
"I use it really; please emit it anyway", meaning much the same thing.
Or something like that.
--
dwmw2
On Thu, Oct 14, 2004 at 10:02:43PM +0100, Russell King wrote:
>
> I notice that module.h contains stuff like:
>
> #define MODULE_GENERIC_TABLE(gtype,name) \
> extern const struct gtype##_id __mod_##gtype##_table \
> __attribute__ ((unused, alias(__stringify(name))))
>
> and even:
>
> #define __MODULE_INFO(tag, name, info) \
> static const char __module_cat(name,__LINE__)[] \
> __attribute_used__ \
> __attribute__((section(".modinfo"),unused)) = __stringify(tag) "=" info
>
> My understanding is that we shouldn't be using __attribute__((unused))
> in either of these - can someone confirm.
>
> The second one looks fairly dodgy since we're telling a compiler that
> it's both used and unused. That sounds a bit like a HHGTTG puzzle (you
> have tea and no tea.)
This makes sense, assuming the gcc info pages are correct:
`unused'
This attribute, attached to a function, means that the function is
meant to be possibly unused. GCC will not produce a warning for
this function. GNU C++ does not currently support this attribute
as definitions without parameters are valid in C++.
`used'
This attribute, attached to a function, means that code must be
emitted for the function even if it appears that the function is
not referenced. This is useful, for example, when the function is
referenced only in inline assembly.
So, a function could be "used" and "unused" at the same time:
unused -> don't warn
used -> don't discard
--
Frank
On Fri, 15 Oct 2004, Frank van Maarseveen wrote:
> This makes sense, assuming the gcc info pages are correct:
> `unused'
> This attribute, attached to a function, means that the function is
> meant to be possibly unused. GCC will not produce a warning for
> this function. GNU C++ does not currently support this attribute
> as definitions without parameters are valid in C++.
>
> `used'
> This attribute, attached to a function, means that code must be
> emitted for the function even if it appears that the function is
> not referenced. This is useful, for example, when the function is
> referenced only in inline assembly.
>
> So, a function could be "used" and "unused" at the same time:
>
> unused -> don't warn
> used -> don't discard
Except that "used" already implies no warning as it makes the function
not unused anymore.
Maciej
On Iau, 2004-10-14 at 23:08, Russell King wrote:
> It's the "later compilers" which I'm worried about here - I think they
> defined "unused" to mean "this really really isn't used and you can
> discard it". Hence my concern with the above.
This was the explanation I got some time ago
-- quote --
So "used" cases that used "unused" could break, though older compilers
in essence used "unused" to mean both "used" and "unused". Since
"unused" becomes useless for using in "used" cases, we now must be sure
to use "used" when that's the use that's useful.
-- Roland McGrath
I found it so helpful it became a .sig 8)
On Fri, 15 Oct 2004, Alan Cox wrote:
> On Iau, 2004-10-14 at 23:08, Russell King wrote:
>> It's the "later compilers" which I'm worried about here - I think they
>> defined "unused" to mean "this really really isn't used and you can
>> discard it". Hence my concern with the above.
>
> This was the explanation I got some time ago
>
> -- quote --
>
> So "used" cases that used "unused" could break, though older compilers
> in essence used "unused" to mean both "used" and "unused". Since
> "unused" becomes useless for using in "used" cases, we now must be sure
> to use "used" when that's the use that's useful.
> -- Roland McGrath
>
>
> I found it so helpful it became a .sig 8)
>
Yes. Just like "less" is more than "more"......and whos on first base.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.8 on an i686 machine (5537.79 BogoMips).
Note 96.31% of all statistics are fiction.