From: slash.tmp@free.fr (Mason)
To: linux-arm-kernel@lists.infradead.org
Subject: String literals in __init functions
Date: Wed, 25 Mar 2015 18:56:22 +0100 [thread overview]
Message-ID: <5512F6C6.1020304@free.fr> (raw)
Hello everyone,
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?
Regards.
WARNING: multiple messages have this Message-ID (diff)
From: Mason <slash.tmp@free.fr>
To: Linux ARM <linux-arm-kernel@lists.infradead.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: String literals in __init functions
Date: Wed, 25 Mar 2015 18:56:22 +0100 [thread overview]
Message-ID: <5512F6C6.1020304@free.fr> (raw)
Hello everyone,
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?
Regards.
next reply other threads:[~2015-03-25 17:56 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-25 17:56 Mason [this message]
2015-03-25 17:56 ` String literals in __init functions Mason
2015-03-25 18:01 ` Joe Perches
2015-03-25 18:01 ` Joe Perches
2015-03-26 12:40 ` Mason
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=5512F6C6.1020304@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.