* Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > On 05/25/2011 10:32 AM, Ingo Molnar wrote: > > > >* Paolo Bonzini<pbonzini@xxxxxxxxxx> wrote: > > > >>> In that sense ((section)) is way more robust: there's not really that many > >>> ways to screw that up. Fiddling with the ((constructor)) environment on the > >>> other hand ... > >> > >> Sorry, this is textbook FUD. > > > > I specifically cited the problem of static libraries. They *do > > not work* with ((constructor)). > > ((constructor)) has easily explained semantics: it's the same > semantics as C++ global constructors. If you don't like those, > that's another story. It is a plain *bug* if device initialization is not being executed if kvm is linked into a static library using the regular way of how libraries are created ... No amount of arguing about 'semantics' will change that simple fact: it breaks code so it's a bug. We don't want to rely on a facility that handles boundary conditions in such a poor way. See my prior point: - Also, over the years i have grown to be suspicious of GCC defined extensions. More often than not the GCC project is fixing regressions not by fixing the compiler but by changing the documentation ;-) We got bitten by regressions in asm() behavior in the kernel rather often. In that sense ((section)) is way more robust: there's not really that many ways to screw that up. Fiddling with the ((constructor)) environment on the other hand ... You are demonstrating this phenomenon rather well. You argue against plain old bugs with 'but these are well-defined semantics'. That's not how we deal with bugs in tools/kvm/ really. And then you argue that the bug can be worked around by writing a linker script: > compilation with static libraries: > $ gcc f.c -o f.o -c > $ gcc f1.c -o f1.o -c > $ ar cr f1.a f1.o > $ ld -r f.ld f.o f1.a -o f2.o > $ gcc f2.o -o a.out > $ ./a.out > 12345678 I will rather use linker scripts and less erratic facilities straight away. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
