Messages in this thread | | | Subject | Re: [PATCH v2 0/8] clean up vdso-layout.lds.S | From | Petr Tesarik <> | Date | Tue, 16 Jun 2009 09:53:12 +0200 |
| |
H. Peter Anvin píše v Po 15. 06. 2009 v 11:33 -0700: > Petr Tesarik wrote: > >>> > >> *(COMMON) is BSS, not data... > > > > Very true, but for the vDSO we decided to put both writeable and > > read-only data into one section (called .data for that matter), probably > > to reduce the number of sections and hence also the size of the > > resulting binary. > > > > BSS is neither,
Right. My typing was once again faster than my thinking. I meant initialized vs. uninitialized, of course.
> but I guess for the vDSO there really isn't any such > thing as uninitialized content.
Right, too. I can't even think of a valid use case, so .broken might be the right place for both COMMON and .bss.
> I have to admit feeling funny about that, and I'm wondering if we > shouldn't compile the vDSO with -fno-common.
Oops, sorry. It's already compiled with -fno-common, because it gets inherited from the top-level Makefile's KBUILD_CFLAGS. Sorry for the noise.
Anyway, my feeling is that the whole discussion is a bit academic. If I want to be rigorous, I should take an opt-in approach, i.e. handle all sections that work fine (e.g. also debugging sections) and then put all else into .broken with something like:
.broken { /* All else is dubious. */ *(*) }
But this can become a maintenance PITA. Whenever GCC and/or binutils add a new extension, the linker script would have to be adjusted accordingly. Well, maybe that's even correct, because somebody at least stops and thinks for a while about the implications of the new feature. But I'm not really offering to become the new maintainer of this file.
Comments?
Petr Tesarik
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |