Re: CVS commit: src/sys/dev

[Iain Hibbert <plunky%rya-online.net@localhost>]

On Thu, 26 May 2011, Masao Uebayashi wrote:

> On Thu, May 26, 2011 at 4:41 AM, David Laight <david%l8s.co.uk@localhost> 
> wrote:
> > On Thu, May 26, 2011 at 02:33:38AM +0900, Masao Uebayashi wrote:
> >> >>
> >> >> Modified Files:
> >> >> ? ? ? src/sys/dev/bluetooth: bcsp.c bthub.c btuart.c
> >> >> ? ? ? src/sys/dev/ieee1394: fwdev.c fwmem.c fwohci.c
> >> >>
> >> >> Log Message:
> >> >> Declare cfdrivers using extern rather than including ioconf.h.
> >> >
> >> > surely the point of declaring a variable once in a header file is that it
> >> > then cannot be accidentally declared differently elsewhere?
> >> >
> >> > is ioconf.h so onerous? (it is merely a list of cfdriver declarations)
> >>
> >> ioconf.h is not, but GCC is.
> >>
> >> I found 2 fwmem.o's signatures mismatch between 2 kernels; GENERIC and
> >> another doing only "no ehci" and include GENERIC.  objdump -D shows:
> >>
> >> @@ -956,7 +956,7 @@
> >>  0000000000000000 <.ident>:
> >>     0:  24 4e                   and    $0x4e,%al
> >>     2:  65                      gs
> >> -   3:  74 42                   je     47 <__func__.11035+0x11>
> >> +   3:  74 42                   je     47 <__func__.11034+0x11>
> >>     5:  53                      push   %rbx
> >>     6:  44 24 00                rex.R and    $0x0,%al
> >>
> >> GCC definitely lacks care about reproducibility.
> >
> > I don't think that you can expect the internal symbols generated by gcc to
> > match when code is compiled in different contexts.
>
> Coming to consider what is a "context"..., why do these drivers have
> to include "ioconf.h" to know alll the other cfdriver decls?  If these
> really need their own cfdriver decl, these unnecessarily widen
> contents, which is, if not a bug, confusing.
>
> Ultimately all (MI) drivers will become modules.  Which means all
> objects will have to become bit-identical across kernels.  Drivers
> including "ioconf.h" is doing something opposite.

So, that is a different issue.. to be fixed by changing usr.bin/config to
not generate the ioconf.h file? (etc.. :-)

> (So I'd withdraw a comment that GCC is onerous.)

the problem that you worked around is that GCC 4.1.3 emits a symbol for
the use of __func__ which depends on an internal counter (__func__.*),
rather than a local symbol (L*) which would normally be stripped or
ignored..

% cat foo.c
void
foo(void)
{
        const char *p = __func__;
}
% gcc -S foo.c
% cat foo.s
        .file   "foo.c"
        .section        .rodata
        .type   __func__.1280, @object
        .size   __func__.1280, 4
__func__.1280:
        .string "foo"
        .text
.globl foo
        .type   foo, @function
foo:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $16, %esp
        movl    $__func__.1280, -4(%ebp)
        leave
        ret
        .size   foo, .-foo
        .ident  "GCC: (GNU) 4.1.3 20080704 prerelease (NetBSD nb2 20081120)"

I wonder if that can be worked around by stripping or ignoring the thing
you want to ignore (non-global symbols), rather than potentially
introducing type inconsistency bugs? ("objcopy -x" will discard all
non-global symbols, I don't know if that is too much)

or, does modern GCC have the same issue?

you might note that the bthub.o file (at least, I didn't check the others)
does not actually use __func__ (unless DEBUG) and in fact the objdump does
not change with the removal of "ioconf.h"

iain