[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/dev
On Thu, 26 May 2011, Masao Uebayashi wrote:
> On Thu, May 26, 2011 at 4:41 AM, David Laight <david%l8s.co.uk@localhost>
> > 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
% cat foo.c
const char *p = __func__;
% gcc -S foo.c
% cat foo.s
.type __func__.1280, @object
.size __func__.1280, 4
.type foo, @function
movl %esp, %ebp
subl $16, %esp
movl $__func__.1280, -4(%ebp)
.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"
Main Index |
Thread Index |