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.
But anyway, I specifically cited the reason why ((section)) is not any
better, AFAIU how you would use it. Now I didn't trust myself and tried it.
f.ld:
SECTIONS {
.paolo : {
PROVIDE(__paolo_start = .);
*(.paolo)
PROVIDE(__paolo_end = .);
}
}
f.c:
int x __attribute__((section(".paolo"))) = 0x12345678;
int main()
{
extern int __paolo_start[];
extern int __paolo_end[];
int *p;
for (p = __paolo_start; p < __paolo_end; p++) {
printf ("%x\n", *p);
}
}
f1.c:
int y __attribute__((section(".paolo"))) = 0x76543210;
compilation with objects:
$ gcc f.c -o f.o -c
$ gcc f1.c -o f1.o -c
$ ld -r f.ld f.o f1.o -o f2.o
$ gcc f2.o -o a.out
$ ./a.out
12345678
76543210
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
Since this is userspace, you do not have complete control on the build
and you still need to use gcc to drive the final link.
So you get exactly the same semantics as ((constructor)), plus one extra
build step that spits out a warning ("ld: warning: f.ld contains output
sections; did you forget -T?").
__attribute__((constructor)) is not particularly portable to begin with:
does the MSVC compiler support it for example?
No, but GCC supports it on non-ELF platforms, [...]
So you claim that ((section)) is 'not portable' but concede that it does in
fact not port to one of the most widely used compilers.
Can you please avoid trimming messages? I said "the differences between
MSVC and GCC can easily be abstracted with a macro". This is not unlike
other differences between the two compilers (e.g. __forceinline vs. the
((always_inline)) attribute), and it is not true of linker scripts.
Instead you clarify that under 'not portable' you really meant to say that
((section)) does not work on non-ELF binary platforms.
That is a pretty inconsistent position and has nothing to do with 'portability'
in itself but with being portable to what *you* consider important.
My definition of "(reasonably) portable" includes having to write a
5-line macro that works across _all_ GCC targets and _all_ MSVC targets.
Having to change the build process for every compiler target (see the
above "ld -r" step) is a bit more unportable, though not much.
Potentially having to modify the custom linker script for every targeted
architecture (the above doesn't work for mingw32, it needs an extra _ in
front of the start/end symbols) is pretty much my definition of
"unportable".
Paolo
--
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
