Re: CVS commit: src/sys/dev

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Thu, May 26, 2011 at 8:24 PM, Iain Hibbert <plunky%rya-online.net@localhost> 
wrote:
> On Thu, 26 May 2011, Masao Uebayashi wrote:
>
>> On Thu, May 26, 2011 at 5:39 PM, Iain Hibbert 
>> <plunky%rya-online.net@localhost> wrote:
>> > On Thu, 26 May 2011, Masao Uebayashi wrote:
>> >> - I can't think of how cfdriver decls can lead to type inconsistency bugs.
>> >
>> > Ok, somebody makes a mistake and writes
>> >
>> > extern struct cfdata foo_cd;
>> >
>> > and it works by chance because the address was zero anyway, then later
>> > something else is changed around and all of a sudden, an innocent code
>> > causes a kernel panic..
>>
>> cfdriver must exist for either embedded/module forms.  If not, it
>> should cause link error (if I'm not missing anything).
>
> Of course, it would exist.. that is the bug
>
> file a: /* generated by config(1) */
>        struct cfdriver foo_cd;
>
> file b: /* generated by an inattentive programmer */
>        extern struct cfdata foo_cd;

I see.  Let's fix hundreds of these instances now.

>> > ok but why change files not affected?  You did not actually remove all
>> > inclusions of "ioconf.h" in any case.. (grep ioconf.h *.d finds two more
>> > in i386/GENERIC, I didn't look at any other arch)
>>
>> Hopefully I'll remove all ioconf.h references in sys/ soon.
>
> I think technically this is a bug in gcc which should be fixed there,
> rather than worked around by diluting our sources..  if gcc would simply
> generate a label of ".Lnnnnn" for what is a local object, then the symbol
> would not appear in the .o file
>
> for instance, pcc does generate such a label and the object code is thus
> unchanged. I don't know about clang, or later gcc versions which we may
> have access to at some point, the bug may have been fixed already?
>
> iain

I'm not sure if this is really a bug, but this behavior happened to be
beneficial to finding modularity bugs.  I hope this won't be fixed
soon. ;)