This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: section placement q


Linus Torvalds wrote:
> 
> 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.

yes.  We've asked the compiler to place the struct in .foosect but not
the string.  It does this, but it is not what we want.

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

There are several similar instances where the behaviour we want is
different.

I reported one of these - it was the

	if (0)
	{
		foo("some_string");
	}

problem.

I'll detail them below.

> ...
> It certainly doesn't handle the generic case
> for the automatic link-time garbage-collection, which is what I assume
> you're working on..

Actually, no.  My itch is that fact that marking an array of structs
(3c59x.c:vortex_info_tbl[]) as __devinitdata puts the array into section
.data.init, but the strings remain in .rodata.  Not what we want.


Let's itemise the things we _do_ want:

-ffunction-sections
-------------------

foo()
{
        bar("hello, world\n");
}
gcc-experimental -ffunction-sections -fdata-sections -O -S fs.c

In this case, the function goes in ".text.foo", but the string goes into
.rodata.  We (Graham) would like the string in ".data.foo", I guess.

__attribute__ (__section__)
---------------------------

void __attribute__ ((__section__ (".some_section"))) foo(void)
{
        bar("hello, world\n");
}

The string goes into .rodata.  We'd like it in <where?>

inline
------

extern inline foo(char *s)
{
}

bar()
{
        foo("hello\n");
}

The string hangs around in .data, unreferenced.  This is a dead-code
(dead data?) elimination issue, rather than a section-fiddling issue. 
Martin Loewis has entered this in gnats.

anon strings in static defns
----------------------------

struct thing
{
        int i;
        char *s;
};

struct thing __attribute__ ((__section__ (".text.init"))) things[]  =
{
        { 12, "a string" }
};

The string goes in .rodata.  We'd like to be able to control its
section. In this case ".data.init".




We either need a way of telling the compiler to divert '.rodata', or a
construct like:

foo()
{
        char *p;

        p = __attribute__ ((__section__ (".some_section"))) "hello";
}

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]