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