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;
> > 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
