From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753359AbbCZWP7 (ORCPT ); Thu, 26 Mar 2015 18:15:59 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:58751 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752435AbbCZWP6 (ORCPT ); Thu, 26 Mar 2015 18:15:58 -0400 Date: Thu, 26 Mar 2015 15:15:57 -0700 From: Andrew Morton To: Joe Perches Cc: gcc@gcc.gnu.org, Mathias Krause , Mason , Linux ARM , LKML , Ingo Molnar Subject: Re: String literals in __init functions Message-Id: <20150326151557.61dfad84272aff10aaa4eba7@linux-foundation.org> In-Reply-To: <1427407120.15849.34.camel@perches.com> References: <5512F6C6.1020304@free.fr> <1427306517.2717.0.camel@perches.com> <5513FE2F.3040306@free.fr> <1427386390.15849.13.camel@perches.com> <1427392393.15849.16.camel@perches.com> <20150326144058.56ef6916b00ad38030296089@linux-foundation.org> <1427407120.15849.34.camel@perches.com> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 26 Mar 2015 14:58:40 -0700 Joe Perches wrote: > > I'd have thought that a function-wide > > __attribute__((__string_section__(foo)) > > wouldn't be a ton of work to implement. > > Maybe not. > > Could some future version of gcc move string constants > in a function to a specific section marked in a manner > similar to what Andrew described above? One thing which might complexicate this is void foo() { p("bar"); } void __attribute__((__string_section__(.init.rodata)) zot() { p("bar"); } It would be silly to create two instances of "bar". Change it thusly: #define __mark_str(str) \ ({ static const char var[] __attribute__((__section__(".init.string"))) = str; var; }) void foo() { p("bar"); } void zot() { p(__mark_str("bar")); } and we indeed get two copies of "bar". It would be nice not to do that, but I guess that losing this optimization is a reasonable compromise.