From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
To: "danielmentz@google.com" <danielmentz@google.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Vineet Gupta" <Vineet.Gupta1@synopsys.com>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>
Subject: Re: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch to .eh_frame)
Date: Fri, 23 Sep 2016 10:38:37 +0000 [thread overview]
Message-ID: <1474627107.2562.19.camel@synopsys.com> (raw)
In-Reply-To: <CAE2F3rBR872+M=mm7Qa5cccrtmOOp5cyZKSWjc4ytOG717jxKQ@mail.gmail.com>
Hi Daniel,
On Thu, 2016-09-22 at 15:37 -0700, Daniel Mentz wrote:
> On Thu, Sep 22, 2016 at 1:59 PM, Vineet Gupta
> <Vineet.Gupta1@synopsys.com> wrote:
> >
> > Hi Daniel,
> >
> > On 09/19/2016 06:21 PM, Daniel Mentz wrote:
> > >
> > > I confirmed that the .eh_frame section is present and that the
> > > .debug_frame section is absent. I also verified that the file size of
> > > the .ko files are small enough for our embedded platform and that
> > > unnecessary sections like .debug_info, .debug_line, .debug_str etc.
> > > are also absent.
> >
> > BTW it seems with my latest set of patches, modules still have .debug_*.
> > Can you double check if your tree still has the interim patch which added a linker
> > script for modules to strip out .debug_*
> >
> > http://lists.infradead.org/pipermail/linux-snps-arc/2016-September/001483.html
>
> Hi Vineet,
>
> Sorry, that was a misunderstanding. Buildroot routinely runs the strip
> command on .ko files before installing them on the target. I was only
> looking at the .ko files *after* running the strip command. No, the
> interim patch was not in my tree.
Well are you sure buildroot really touches modules in Linux kernel build folder?
Buildroot just runs a simple "make" command in "output/build/linux-x.y".
And only on installation step Buildroot strips binaries in "output/target" folder.
Moreover starting from that commit
https://git.buildroot.net/buildroot/commit/?id=10c4d27aef4dca01572cfc8146cbfd194a1a85e4
even on Linux installation step Buildroot reuses kernel's module stripping infrastructure
but again that happens only on target.
Just in case that's what I see when building MSDOSFS as module.
In build folder:
----------------------------->8-------------------------------
arc-linux-readelf -S build/linux-4.7.3/fs/fat/msdos.ko
There are 38 section headers, starting at offset 0x2a630:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .note.gnu.build-i NOTE 00000000 000034 000024 00 A 0 0 4
[ 2] .text PROGBITS 00000000 000058 0013a8 00 AX 0 0 4
[ 3] .rela.text RELA 00000000 01c774 000600 0c I 35 2 4
[ 4] .init.text PROGBITS 00000000 001400 000010 00 AX 0 0 4
[ 5] .rela.init.text RELA 00000000 01cd74 000018 0c I 35 4 4
[ 6] .exit.text PROGBITS 00000000 001410 000010 00 AX 0 0 4
[ 7] .rela.exit.text RELA 00000000 01cd8c 000018 0c I 35 6 4
[ 8] .rodata PROGBITS 00000000 001440 000100 00 A 0 0 64
[ 9] .rela.rodata RELA 00000000 01cda4 000078 0c I 35 8 4
[10] .modinfo PROGBITS 00000000 001540 000090 00 A 0 0 4
[11] .rodata.str1.4 PROGBITS 00000000 0015d0 000030 01 AMS 0 0 4
[12] .data PROGBITS 00000000 001600 00002c 00 WA 0 0 4
[13] .rela.data RELA 00000000 01ce1c 000030 0c I 35 12 4
[14] .gnu.linkonce.thi PROGBITS 00000000 001640 000140 00 WA 0 0 64
[15] .rela.gnu.linkonc RELA 00000000 01ce4c 00000c 0c I 35 14 4
[16] .tdata PROGBITS 00000000 001780 000000 00 WAT 0 0 1
[17] .tbss NOBITS 00000000 001780 000000 00 WAT 0 0 1
[18] .bss NOBITS 00000000 001780 000000 00 WA 0 0 1
[19] .comment PROGBITS 00000000 001780 000078 01 MS 0 0 1
[20] .note.GNU-stack PROGBITS 00000000 0017f8 000000 00 0 0 1
[21] .debug_aranges PROGBITS 00000000 0017f8 000048 00 0 0 1
[22] .rela.debug_arang RELA 00000000 01ce58 00003c 0c I 35 21 4
[23] .debug_info PROGBITS 00000000 001840 00eaa9 00 0 0 1
[24] .rela.debug_info RELA 00000000 01ce94 00a53c 0c I 35 23 4
[25] .debug_abbrev PROGBITS 00000000 0102e9 0008b3 00 0 0 1
[26] .debug_line PROGBITS 00000000 010b9c 001d4d 00 0 0 1
[27] .rela.debug_line RELA 00000000 0273d0 001818 0c I 35 26 4
[28] .debug_frame PROGBITS 00000000 0128ec 0002d8 00 0 0 4
[29] .rela.debug_frame RELA 00000000 028be8 000168 0c I 35 28 4
[30] .debug_str PROGBITS 00000000 012bc4 008485 01 MS 0 0 1
[31] .debug_loc PROGBITS 00000000 01b049 000b49 00 0 0 1
[32] .rela.debug_loc RELA 00000000 028d50 001308 0c I 35 31 4
[33] .debug_ranges PROGBITS 00000000 01bb92 0001f8 00 0 0 1
[34] .rela.debug_range RELA 00000000 02a058 000480 0c I 35 33 4
[35] .symtab SYMTAB 00000000 01bd8c 0005e0 10 36 53 4
[36] .strtab STRTAB 00000000 01c36c 000407 00 0 0 1
[37] .shstrtab STRTAB 00000000 02a4d8 000157 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
p (processor specific)
----------------------------->8-------------------------------
On target:
----------------------------->8-------------------------------
arc-linux-readelf -S target/lib/modules/4.7.3/kernel/fs/fat/msdos.ko
There are 24 section headers, starting at offset 0x28e0:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .note.gnu.build-i NOTE 00000000 000034 000024 00 A 0 0 4
[ 2] .text PROGBITS 00000000 000058 0013a8 00 AX 0 0 4
[ 3] .rela.text RELA 00000000 002128 000600 0c I 21 2 4
[ 4] .init.text PROGBITS 00000000 001400 000010 00 AX 0 0 4
[ 5] .rela.init.text RELA 00000000 002728 000018 0c I 21 4 4
[ 6] .exit.text PROGBITS 00000000 001410 000010 00 AX 0 0 4
[ 7] .rela.exit.text RELA 00000000 002740 000018 0c I 21 6 4
[ 8] .rodata PROGBITS 00000000 001440 000100 00 A 0 0 64
[ 9] .rela.rodata RELA 00000000 002758 000078 0c I 21 8 4
[10] .modinfo PROGBITS 00000000 001540 000090 00 A 0 0 4
[11] .rodata.str1.4 PROGBITS 00000000 0015d0 000030 01 AMS 0 0 4
[12] .data PROGBITS 00000000 001600 00002c 00 WA 0 0 4
[13] .rela.data RELA 00000000 0027d0 000030 0c I 21 12 4
[14] .gnu.linkonce.thi PROGBITS 00000000 001640 000140 00 WA 0 0 64
[15] .rela.gnu.linkonc RELA 00000000 002800 00000c 0c I 21 14 4
[16] .tdata PROGBITS 00000000 001780 000000 00 WAT 0 0 1
[17] .tbss NOBITS 00000000 001780 000000 00 WAT 0 0 1
[18] .bss NOBITS 00000000 001780 000000 00 WA 0 0 1
[19] .comment PROGBITS 00000000 001780 000078 01 MS 0 0 1
[20] .note.GNU-stack PROGBITS 00000000 0017f8 000000 00 0 0 1
[21] .symtab SYMTAB 00000000 0017f8 000540 10 22 43 4
[22] .strtab STRTAB 00000000 001d38 0003ed 00 0 0 1
[23] .shstrtab STRTAB 00000000 00280c 0000d3 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
p (processor specific)
----------------------------->8-------------------------------
-Alexey
next prev parent reply other threads:[~2016-09-23 10:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-19 21:49 [PATCH 0/3] ARC unwinder switch to .eh_frame Vineet Gupta
2016-09-19 21:49 ` [PATCH 1/3] ARC: module: support R_ARC_32_PCREL relocation Vineet Gupta
2016-09-19 21:49 ` [PATCH 2/3] ARC: dw2 unwind: factor CIE specifics for .eh_frame/.debug_frame Vineet Gupta
2016-09-19 21:49 ` [PATCH 3/3] ARC: dw2 unwind: switch to .eh_frame based unwinding Vineet Gupta
2016-09-20 1:21 ` [PATCH 0/3] ARC unwinder switch to .eh_frame Daniel Mentz
2016-09-20 6:13 ` Vineet Gupta
2016-09-22 20:39 ` Vineet Gupta
2016-09-22 20:59 ` modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch to .eh_frame) Vineet Gupta
2016-09-22 22:37 ` Daniel Mentz
2016-09-23 10:38 ` Alexey Brodkin [this message]
2016-09-24 1:04 ` Daniel Mentz
2016-09-26 12:38 ` Alexey Brodkin
2016-09-26 18:51 ` Daniel Mentz
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=1474627107.2562.19.camel@synopsys.com \
--to=alexey.brodkin@synopsys.com \
--cc=Vineet.Gupta1@synopsys.com \
--cc=danielmentz@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-snps-arc@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).