Re: [PATCH v3 1/3] Make section names compatible with -ffunction-sections-fdata-sections

[Tim Abbott]

On Sun, 26 Apr 2009, Sam Ravnborg wrote:

> I was not specific in my last mail about this - but I assume you have
> understood that the naming ".head.text" was selected so it is compatible
> wiht -ffunction-sections. In other words no need for any ugly ".." here.

Yes, I did notice this.  However, I think that the ".text..foo" naming 
scheme is a better choice than the ".head.text" naming scheme.

One advantage is that it works better if people add new assembly code in 
that section without using the proper macros.  With ".head.text", if 
someone were to naively write ".section .head.text", the section would not 
have the SEC_ALLOC flag set.  With ".text..head", gcc will assume the "ax" 
section flags, and everything will work fine.

More importantly, the .head.text naming scheme fails for BSS sections.  
If you replace

__attribute__((__section__(".bss.page_aligned")));

with 

__attribute__((__section__(".page_aligned.bss")));

then you get section flags of @progbits rather than @nobits, which is 
inappropriate for bss.  The ".bss..page_aligned" naming scheme supports 
this just fine.

Since it is desirable to have the Linux magic section names all use a 
single naming scheme, this is why we settled on the .text..foo section 
naming style.

> We should try to be as consistent as possible across architectures here
> so it is better to toach a few additiona files rather than adding macros
> and the like to accept there sub-optimal section naming.

I'm OK with doing this.  But I prefer to avoid having ".head.text" appear 
in all these places as it encourages people to write new code using 
".head.text".

Also, as discussed above, we may want to change the name to ".text..head" 
for consistency in the future, and having everything use the macros makes 
this really easy.

	-Tim Abbott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/