Re: CVS commit: src/sys/dev

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

On Thu, May 26, 2011 at 4:24 PM, Iain Hibbert <plunky%rya-online.net@localhost> 
wrote:
> 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)

- I want to keep reproducibility even in intermediate files for better
traceability.
- I can't think of how cfdriver decls can lead to type inconsistency bugs.

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

Right, bthub.o is not affected.  fwmem.o is.

>
> iain