On Thu, May 26, 2011 at 8:24 PM, Iain Hibbert <plu...@rya-online.net> wrote: > On Thu, 26 May 2011, Masao Uebayashi wrote: > >> On Thu, May 26, 2011 at 5:39 PM, Iain Hibbert <plu...@rya-online.net> 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. ;)
