All of lore.kernel.org
 help / color / mirror / Atom feed
From: slash.tmp@free.fr (Mason)
To: linux-arm-kernel@lists.infradead.org
Subject: String literals in __init functions
Date: Thu, 26 Mar 2015 13:40:15 +0100	[thread overview]
Message-ID: <5513FE2F.3040306@free.fr> (raw)
In-Reply-To: <1427306517.2717.0.camel@perches.com>

On 25/03/2015 19:01, Joe Perches wrote:

> On Wed, 2015-03-25 at 18:56 +0100, Mason wrote:
>
>> AFAIU, functions only used at system init are tagged __init to have
>> the linker store them in a separate .init.text section, so memory can
>> be reclaimed once initialization is complete. Is that correct?
>>
>> The corresponding tag for data is __initdata (section .init.data)
>>
>> I started wondering if the string literals used in an __init functions
>> were automatically marked __initdata.
>>
>> Looking at the objdump output, I see that the string literals are,
>> in fact, stored in the .rodata section. I suppose that .rodata is NOT
>> reclaimed after init?
>>
>> This way seems to work:
>>
>> static       char XyZa[] __initdata  = KERN_ALERT "foo";
>> static const char XyZb[] __initconst = KERN_ALERT "bar";
>> void __init XyZc(void) { printk(XyZa); printk(XyZb); }
>>
>> $ arm-linux-gnueabihf-objdump -xd arch/arm/mach-tangox/time.o | grep XyZ
>> 00000000 l     O .init.data	00000006 XyZa
>> 00000000 l     O .init.rodata	00000006 XyZb
>> 00000000 g     F .init.text	00000028 XyZc
>> 00000000 <XyZc>:
>>
>> $ arm-linux-gnueabihf-objdump -xd vmlinux | grep XyZ
>> c021e360 l     O .init.data	00000006 XyZa
>> c0220090 l     O .init.data	00000006 XyZb
>> c020d928 g     F .init.text	00000028 XyZc
>> c020d928 <XyZc>:
>>
>> c020d928 <XyZc>:
>> c020d928:       e1a0c00d        mov     ip, sp
>> c020d92c:       e92dd800        push    {fp, ip, lr, pc}
>> c020d930:       e24cb004        sub     fp, ip, #4
>> c020d934:       e30e0360        movw    r0, #58208      ; 0xe360
>> c020d938:       e34c0021        movt    r0, #49185      ; 0xc021
>> c020d93c:       ebfe00c9        bl      c018dc68 <printk>
>> c020d940:       e3000090        movw    r0, #144        ; 0x90
>> c020d944:       e34c0022        movt    r0, #49186      ; 0xc022
>> c020d948:       ebfe00c6        bl      c018dc68 <printk>
>> c020d94c:       e89da800        ldm     sp, {fp, sp, pc}
>>
>> Did I miss something in init.h?
>> Or should it be done like above to reclaim string literals?
>
> No, you didn't miss anything.
>
> One proposal:
>
> https://lkml.org/lkml/2014/8/21/255

Thanks for the link!

Here's the equivalent gmane link for my own reference:
http://thread.gmane.org/gmane.linux.kernel/1771969

Basically, if I understand correctly, Ingo NAKed the patch, saying
this should be done automatically by the toolchain. That would make
for an interesting side-project...

For the record, I wrote a trivial wrapper for my limited use-case.

#define printk_init(format, ...) do { \
   static char fmt[] __initdata = format; printk(fmt, ## __VA_ARGS__); \
} while(0)

(I dislike the "statement-in-expression" extension, because vim thinks
there's a syntax error, and flashes a bright red block.)

https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html
https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html

Regards.

WARNING: multiple messages have this Message-ID (diff)
From: Mason <slash.tmp@free.fr>
To: Joe Perches <joe@perches.com>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Mathias Krause <minipli@gmail.com>
Subject: Re: String literals in __init functions
Date: Thu, 26 Mar 2015 13:40:15 +0100	[thread overview]
Message-ID: <5513FE2F.3040306@free.fr> (raw)
In-Reply-To: <1427306517.2717.0.camel@perches.com>

On 25/03/2015 19:01, Joe Perches wrote:

> On Wed, 2015-03-25 at 18:56 +0100, Mason wrote:
>
>> AFAIU, functions only used at system init are tagged __init to have
>> the linker store them in a separate .init.text section, so memory can
>> be reclaimed once initialization is complete. Is that correct?
>>
>> The corresponding tag for data is __initdata (section .init.data)
>>
>> I started wondering if the string literals used in an __init functions
>> were automatically marked __initdata.
>>
>> Looking at the objdump output, I see that the string literals are,
>> in fact, stored in the .rodata section. I suppose that .rodata is NOT
>> reclaimed after init?
>>
>> This way seems to work:
>>
>> static       char XyZa[] __initdata  = KERN_ALERT "foo";
>> static const char XyZb[] __initconst = KERN_ALERT "bar";
>> void __init XyZc(void) { printk(XyZa); printk(XyZb); }
>>
>> $ arm-linux-gnueabihf-objdump -xd arch/arm/mach-tangox/time.o | grep XyZ
>> 00000000 l     O .init.data	00000006 XyZa
>> 00000000 l     O .init.rodata	00000006 XyZb
>> 00000000 g     F .init.text	00000028 XyZc
>> 00000000 <XyZc>:
>>
>> $ arm-linux-gnueabihf-objdump -xd vmlinux | grep XyZ
>> c021e360 l     O .init.data	00000006 XyZa
>> c0220090 l     O .init.data	00000006 XyZb
>> c020d928 g     F .init.text	00000028 XyZc
>> c020d928 <XyZc>:
>>
>> c020d928 <XyZc>:
>> c020d928:       e1a0c00d        mov     ip, sp
>> c020d92c:       e92dd800        push    {fp, ip, lr, pc}
>> c020d930:       e24cb004        sub     fp, ip, #4
>> c020d934:       e30e0360        movw    r0, #58208      ; 0xe360
>> c020d938:       e34c0021        movt    r0, #49185      ; 0xc021
>> c020d93c:       ebfe00c9        bl      c018dc68 <printk>
>> c020d940:       e3000090        movw    r0, #144        ; 0x90
>> c020d944:       e34c0022        movt    r0, #49186      ; 0xc022
>> c020d948:       ebfe00c6        bl      c018dc68 <printk>
>> c020d94c:       e89da800        ldm     sp, {fp, sp, pc}
>>
>> Did I miss something in init.h?
>> Or should it be done like above to reclaim string literals?
>
> No, you didn't miss anything.
>
> One proposal:
>
> https://lkml.org/lkml/2014/8/21/255

Thanks for the link!

Here's the equivalent gmane link for my own reference:
http://thread.gmane.org/gmane.linux.kernel/1771969

Basically, if I understand correctly, Ingo NAKed the patch, saying
this should be done automatically by the toolchain. That would make
for an interesting side-project...

For the record, I wrote a trivial wrapper for my limited use-case.

#define printk_init(format, ...) do { \
   static char fmt[] __initdata = format; printk(fmt, ## __VA_ARGS__); \
} while(0)

(I dislike the "statement-in-expression" extension, because vim thinks
there's a syntax error, and flashes a bright red block.)

https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html
https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html

Regards.



  reply	other threads:[~2015-03-26 12:40 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-25 17:56 String literals in __init functions Mason
2015-03-25 17:56 ` Mason
2015-03-25 18:01 ` Joe Perches
2015-03-25 18:01   ` Joe Perches
2015-03-26 12:40   ` Mason [this message]
2015-03-26 12:40     ` Mason
2015-03-26 16:13     ` Joe Perches
2015-03-26 16:13       ` Joe Perches
2015-03-26 16:37       ` Mathias Krause
2015-03-26 16:37         ` Mathias Krause
2015-03-26 17:53         ` Joe Perches
2015-03-26 17:53           ` Joe Perches
2015-03-26 20:49           ` Mathias Krause
2015-03-26 20:49             ` Mathias Krause
2015-03-26 21:40             ` Andrew Morton
2015-03-26 21:40               ` Andrew Morton
2015-03-26 21:58               ` Joe Perches
2015-03-26 21:58                 ` Joe Perches
2015-03-26 22:15                 ` Andrew Morton
2015-03-26 22:15                   ` Andrew Morton
2015-03-27  7:16                   ` Mathias Krause
2015-03-27  7:16                     ` Mathias Krause
2015-04-02 16:00                 ` Joseph Myers
2015-04-02 16:00                   ` Joseph Myers
2015-04-02 16:23                   ` Joe Perches
2015-04-02 16:23                     ` Joe Perches
2015-03-27  7:05               ` Mathias Krause
2015-03-27  7:05                 ` Mathias Krause
2015-03-27  7:32                 ` Joe Perches
2015-03-27  7:32                   ` Joe Perches

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5513FE2F.3040306@free.fr \
    --to=slash.tmp@free.fr \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.