Re: section placement q

[Linus Torvalds <torvalds at transmeta dot com>]

In article <391B5AF7.C26E47E4@uow.edu.au> you write:
>The linux kernel likes to put lots of things into special sections so
>those sections can be unloaded when not neeed.  However this is less
>effective than it might be because strings are still placed in .rodata. 
>Example:
>
>struct foo
>{
>        int i;
>        char *s;
>};
>
>struct foo foo_array[] __attribute__ ((__section__(".foosect"))) =
>{
>        { 12, "foo1" }
>};
>
>Here, the integer and the char * are placed in .foosect, but the actual
>string "foo1\0" is placed in .rodata.
>
>I believe this behaviour is correct and logical.  One probably unpopular
>workaround is to change 'char *s' into 'char s[20]'.

I don't think this is necessarily logical, although "correct" is
obviously simply a definition question. It depends on what you want. In
many cases it might be advantageous to be able to specify where the
initialiser goes regardless of where the actual data is. I can imagine
cases where you might have

	struct char * name __attribute__((__section(".namesection"))) =
		(char [] __attribute__((__section__(".stringsection"))) "foo";

Ugly as hell, but certainly flexible.  And anybody sane would hide this
behind macros anyway, if for no other reason than portability. 

(I actually think that the "unused inline function that has a string"
case is more important, but I think that got fixed already, no?)

>Can anyone suggest a construct which will allow the string to be placed
>in a different section while retaining the current 'char *' semantics?

Have you looked at how the kernel build handles the PCI "names" issue?
This was one case where the string list is _huge_, and we obviously want
to drop it after booting and naming only the devices we have (as opposed
to every single PCI name in existence).  So it uses generated code to do
what we want - ugly, but works, and causes all strings to be in the
".init" section. 

Of course, as the PCI name database is generated anyway, this solution
works fine for that case. It certainly doesn't handle the generic case
for the automatic link-time garbage-collection, which is what I assume
you're working on..

		Linus