Messages in this thread | | | Date | Wed, 25 Jun 2014 10:17:47 +0200 | Subject | Re: [RFC PATCH 0/3] Mark literal strings in __init / __exit code | From | Mathias Krause <> |
| |
On 25 June 2014 09:35, Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote: > Mathias Krause <minipli@googlemail.com> writes: > >> On 24 June 2014 16:31, Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote: >>> gcc already seems to contain infrastructure for this kind of thing, so >>> maybe it doesn't even require a plugin, but simply a little coordination >>> with the gcc folks. This snippet from gcc internals seems relevant: >>> >>> -- Target Hook: section * TARGET_ASM_FUNCTION_RODATA_SECTION (tree >>> DECL) >>> Return the readonly data section associated with 'DECL_SECTION_NAME >>> (DECL)'. The default version of this function selects >>> '.gnu.linkonce.r.name' if the function's section is >>> '.gnu.linkonce.t.name', '.rodata.name' if function is in >>> '.text.name', and the normal readonly-data section otherwise. >>> >> >> I don't think it's that easy. You cannot simply put all strings into >> the .init.rodata section when code currently gets emitted to >> .init.text. The reason is because strings used in __init code might be >> referenced later on, too. For example, the name passed to >> class_create() won't be copied. > > Right, didn't think about that, so yes, the source would need > to be annotated some way or other, or gcc would need to learn the > semantics of certain kernel functions.
I would rather like to avoid the latter.
> > Speaking of dangling pointers: A similar disaster would happen if some > code containing pi_* calls gets copy-pasted to some non-__init > function. Could checkpatch learn to warn about calling these functions > from the wrong context?
But the same is already true for code. If an __init function gets referenced from a non-__init function, the same dangling references would occur. That's what scripts/mod/modpost is for -- detecting such cases and warn about them. So this is already handled by the kernel build system. A checkpatch warning might be a nice addition, anyway.
> > Mathias Krause <minipli@googlemail.com> writes: > >> Merging strings across multiple compilation units does not happen, >> anyway -- not now, not with the new macros. > > Certainly string merging seems to happen, at least at -O1 and higher: > > $ grep . *.c > a.c:const char *a(void) { return "654321"; } > b.c:const char *b(void) { return "4321"; } > c.c:const char *c(void) { return "654321"; } > main.c:#include <stdio.h> > main.c:const char *a(void); > main.c:const char *b(void); > main.c:const char *c(void); > main.c:int main(void) > main.c:{ > main.c: printf("%p\n", a()); > main.c: printf("%p\n", b()); > main.c: printf("%p\n", c()); > main.c: return 0; > main.c:} > $ gcc -O1 -c a.c && gcc -O1 -c b.c && gcc -O1 -c c.c > $ gcc -O1 main.c a.o b.o c.o > $ ./a.out > 0x400630 > 0x400632 > 0x400630 > > So not only are identical strings merged; suffixes are also optimized.
Oh, indeed! But they're luckily not merged across sections. So no problems with dangling pointers here, too.
Thanks, Mathias
| |