On Thu, May 26, 2011 at 4:24 PM, Iain Hibbert <plu...@rya-online.net> wrote:
> On Thu, 26 May 2011, Masao Uebayashi wrote:
>
>> On Thu, May 26, 2011 at 4:41 AM, David Laight <da...@l8s.co.uk> 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
