lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0904261332110.10199@vinegar-pot.mit.edu>
Date:	Sun, 26 Apr 2009 17:53:42 -0400 (EDT)
From:	Tim Abbott <tabbott@....EDU>
To:	Sam Ravnborg <sam@...nborg.org>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux kernel mailing list <linux-kernel@...r.kernel.org>,
	Anders Kaseorg <andersk@....edu>,
	Waseem Daher <wdaher@....edu>,
	Denys Vlasenko <vda.linux@...glemail.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Andi Kleen <andi@...stfloor.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Jeff Arnold <jbarnold@....edu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jon Masters <jonathan@...masters.org>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	"Theodore Ts'o" <tytso@....edu>,
	Nikanth Karthikesan <knikanth@...e.de>,
	Arjan van de Ven <arjan@...radead.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	Américo Wang <xiyou.wangcong@...il.com>
Subject: Re: [PATCH v3 1/3] Make section names compatible with -ffunction-sections
 -fdata-sections

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ