Re: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch to .eh_frame)

2016-09-26 Thread Daniel Mentz 
On Mon, Sep 26, 2016 at 5:38 AM, Alexey Brodkin
 wrote:
> On Fri, 2016-09-23 at 18:04 -0700, Daniel Mentz wrote:
>> On Fri, Sep 23, 2016 at 3:38 AM, Alexey Brodkin
>>  wrote:
>> >
>> > On Thu, 2016-09-22 at 15:37 -0700, Daniel Mentz wrote:
>> > >
>> > > 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".
>>
>> Sorry, that was phrased badly. Buildroot does not touch the modules in
>> the Linux kernel build folder. Modules are stripped in the target
>> directory as you described.
>
> So every is as expected now for you or there're still thing you don't like?

Yes, everything works as expected now. Thank you for Synposys' support
with this issue.

Re: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch to .eh_frame)

2016-09-26 Thread Daniel Mentz 
On Mon, Sep 26, 2016 at 5:38 AM, Alexey Brodkin
 wrote:
> On Fri, 2016-09-23 at 18:04 -0700, Daniel Mentz wrote:
>> On Fri, Sep 23, 2016 at 3:38 AM, Alexey Brodkin
>>  wrote:
>> >
>> > On Thu, 2016-09-22 at 15:37 -0700, Daniel Mentz wrote:
>> > >
>> > > 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".
>>
>> Sorry, that was phrased badly. Buildroot does not touch the modules in
>> the Linux kernel build folder. Modules are stripped in the target
>> directory as you described.
>
> So every is as expected now for you or there're still thing you don't like?

Yes, everything works as expected now. Thank you for Synposys' support
with this issue.

Re: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch to .eh_frame)

2016-09-26 Thread Alexey Brodkin 
Hi Daniel,

On Fri, 2016-09-23 at 18:04 -0700, Daniel Mentz wrote:
> On Fri, Sep 23, 2016 at 3:38 AM, Alexey Brodkin
>  wrote:
> > 
> > On Thu, 2016-09-22 at 15:37 -0700, Daniel Mentz wrote:
> > > 
> > > 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".
> 
> Sorry, that was phrased badly. Buildroot does not touch the modules in
> the Linux kernel build folder. Modules are stripped in the target
> directory as you described.

So every is as expected now for you or there're still thing you don't like?

-Alexey

Re: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch to .eh_frame)

2016-09-26 Thread Alexey Brodkin 
Hi Daniel,

On Fri, 2016-09-23 at 18:04 -0700, Daniel Mentz wrote:
> On Fri, Sep 23, 2016 at 3:38 AM, Alexey Brodkin
>  wrote:
> > 
> > On Thu, 2016-09-22 at 15:37 -0700, Daniel Mentz wrote:
> > > 
> > > 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".
> 
> Sorry, that was phrased badly. Buildroot does not touch the modules in
> the Linux kernel build folder. Modules are stripped in the target
> directory as you described.

So every is as expected now for you or there're still thing you don't like?

-Alexey

Re: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch to .eh_frame)

2016-09-23 Thread Daniel Mentz 
On Fri, Sep 23, 2016 at 3:38 AM, Alexey Brodkin
 wrote:
> On Thu, 2016-09-22 at 15:37 -0700, Daniel Mentz wrote:
>> 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".

Sorry, that was phrased badly. Buildroot does not touch the modules in
the Linux kernel build folder. Modules are stripped in the target
directory as you described.

> 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.

Re: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch to .eh_frame)

2016-09-23 Thread Daniel Mentz 
On Fri, Sep 23, 2016 at 3:38 AM, Alexey Brodkin
 wrote:
> On Thu, 2016-09-22 at 15:37 -0700, Daniel Mentz wrote:
>> 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".

Sorry, that was phrased badly. Buildroot does not touch the modules in
the Linux kernel build folder. Modules are stripped in the target
directory as you described.

> 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.

Re: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch to .eh_frame)

2016-09-23 Thread Alexey Brodkin 
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
>  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  TypeAddr OffSize   ES Flg Lk Inf Al
  [ 0]   NULL 00 00 00  0   0  0
  [ 1] .note.gnu.build-i NOTE 34 24 00   A  0   0  4
  [ 2] .text PROGBITS 58 0013a8 00  AX  0   0  4
  [ 3] .rela.textRELA 01c774 000600 0c   I 35   2  4
  [ 4] .init.textPROGBITS 001400 10 00  AX  0   0  4
  [ 5] .rela.init.text   RELA 01cd74 18 0c   I 35   4  4
  [ 6] .exit.textPROGBITS 001410 10 00  AX  0   0  4
  [ 7] .rela.exit.text   RELA 01cd8c 18 0c   I 35   6  4
  [ 8] .rodata   PROGBITS 001440 000100 00   A  0   0 64
  [ 9] .rela.rodata  RELA 01cda4 78 0c   I 35   8  4
  [10] .modinfo  PROGBITS 001540 90 00   A  0   0  4
  [11] .rodata.str1.4PROGBITS 0015d0 30 01 AMS  0   0  4
  [12] .data PROGBITS 001600 2c 00  WA  0   0  4
  [13] .rela.dataRELA 01ce1c 30 0c   I 35  12  4
  [14] .gnu.linkonce.thi PROGBITS 001640 000140 00  WA  0   0 64
  [15] .rela.gnu.linkonc RELA 01ce4c 0c 0c   I 35  14  4
  [16] .tdataPROGBITS 001780 00 00 WAT  0   0  1
  [17] .tbss NOBITS   001780 00 00 WAT  0   0  1
  [18] .bss  NOBITS   001780 00 00  WA  0   0  1
  [19] .comment  PROGBITS 001780 78 01  MS  0   0  1
  [20] .note.GNU-stack   PROGBITS 0017f8 00 00  0   0  1
  [21] .debug_arangesPROGBITS 0017f8 48 00  0   0  1
  [22] .rela.debug_arang RELA 01ce58 3c 0c   I 35  21  4
  [23] .debug_info   PROGBITS 001840 00eaa9 00  0   0  1
  [24] .rela.debug_info  RELA 01ce94 00a53c 0c   I 35  23  4
  [25] .debug_abbrev PROGBITS 0102e9 0008b3 00  0   0  1
  [26] .debug_line   PROGBITS 010b9c 001d4d 00  0   0  1
  [27] .rela.debug_line  RELA 0273d0 001818 0c   I 35  26  4
  [28] .debug_frame  PROGBITS 0128ec 0002d8 00  0   0  4
  [29] .rela.debug_frame RELA 028be8 000168 0c   I 35  28  4
  [30] .debug_strPROGBITS 012bc4 008485 01  MS  0   0  1
  [31] .debug_locPROGBITS 01b049 000b49 00  0   0  1
  [32] .rela.debug_loc   RELA 028d50 001308 0c   I 35  31  4
  [33] .debug_ranges PROGBITS 01bb92 0001f8 00  0   0  1
  [34] .rela.debug_range RELA 02a058 000480 0c   I 35  33  4
  [35] .symtab   SYMTAB   01bd8c 0005e0 10 36  53  4
  [36] .strtab   STRTAB   01c36c 000407 00  0   0  1
  [37] .shstrtab 

Re: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch to .eh_frame)

2016-09-23 Thread Alexey Brodkin 
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
>  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  TypeAddr OffSize   ES Flg Lk Inf Al
  [ 0]   NULL 00 00 00  0   0  0
  [ 1] .note.gnu.build-i NOTE 34 24 00   A  0   0  4
  [ 2] .text PROGBITS 58 0013a8 00  AX  0   0  4
  [ 3] .rela.textRELA 01c774 000600 0c   I 35   2  4
  [ 4] .init.textPROGBITS 001400 10 00  AX  0   0  4
  [ 5] .rela.init.text   RELA 01cd74 18 0c   I 35   4  4
  [ 6] .exit.textPROGBITS 001410 10 00  AX  0   0  4
  [ 7] .rela.exit.text   RELA 01cd8c 18 0c   I 35   6  4
  [ 8] .rodata   PROGBITS 001440 000100 00   A  0   0 64
  [ 9] .rela.rodata  RELA 01cda4 78 0c   I 35   8  4
  [10] .modinfo  PROGBITS 001540 90 00   A  0   0  4
  [11] .rodata.str1.4PROGBITS 0015d0 30 01 AMS  0   0  4
  [12] .data PROGBITS 001600 2c 00  WA  0   0  4
  [13] .rela.dataRELA 01ce1c 30 0c   I 35  12  4
  [14] .gnu.linkonce.thi PROGBITS 001640 000140 00  WA  0   0 64
  [15] .rela.gnu.linkonc RELA 01ce4c 0c 0c   I 35  14  4
  [16] .tdataPROGBITS 001780 00 00 WAT  0   0  1
  [17] .tbss NOBITS   001780 00 00 WAT  0   0  1
  [18] .bss  NOBITS   001780 00 00  WA  0   0  1
  [19] .comment  PROGBITS 001780 78 01  MS  0   0  1
  [20] .note.GNU-stack   PROGBITS 0017f8 00 00  0   0  1
  [21] .debug_arangesPROGBITS 0017f8 48 00  0   0  1
  [22] .rela.debug_arang RELA 01ce58 3c 0c   I 35  21  4
  [23] .debug_info   PROGBITS 001840 00eaa9 00  0   0  1
  [24] .rela.debug_info  RELA 01ce94 00a53c 0c   I 35  23  4
  [25] .debug_abbrev PROGBITS 0102e9 0008b3 00  0   0  1
  [26] .debug_line   PROGBITS 010b9c 001d4d 00  0   0  1
  [27] .rela.debug_line  RELA 0273d0 001818 0c   I 35  26  4
  [28] .debug_frame  PROGBITS 0128ec 0002d8 00  0   0  4
  [29] .rela.debug_frame RELA 028be8 000168 0c   I 35  28  4
  [30] .debug_strPROGBITS 012bc4 008485 01  MS  0   0  1
  [31] .debug_locPROGBITS 01b049 000b49 00  0   0  1
  [32] .rela.debug_loc   RELA 028d50 001308 0c   I 35  31  4
  [33] .debug_ranges PROGBITS 01bb92 0001f8 00  0   0  1
  [34] .rela.debug_range RELA 02a058 000480 0c   I 35  33  4
  [35] .symtab   SYMTAB   01bd8c 0005e0 10 36  53  4
  [36] .strtab   STRTAB   01c36c 000407 00  0   0  1
  [37] .shstrtab STRTAB  

Re: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch to .eh_frame)

2016-09-22 Thread Daniel Mentz 
On Thu, Sep 22, 2016 at 1:59 PM, Vineet Gupta
 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.

I confirmed that your commit "ARC: dw2 unwind: don't force dwarf 2" is
indeed necessary to suppress the .debug_* sections when
CONFIG_DEBUG_INFO is off. But again, we're stripping .ko files anyways
before installing.

> I'm not planning to carry it and would prefer addressing the the root cause by
> removing the -gdwarf-2 toggle. I've added that and pushed rebased series. 
> Care to
> take it for a respin please.

I downloaded your latest commit
e47305af57d7eedc10b4720e604d669b10c69e3b and verified that stack
traces are properly displayed for code inside kernel modules as well
as vmlinux. I also called memcpy() on some bad address and got a
proper stack trace that involved memcpy().

I conclude that unwinding works for us.

Thank You
 Daniel

Re: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch to .eh_frame)

2016-09-22 Thread Daniel Mentz 
On Thu, Sep 22, 2016 at 1:59 PM, Vineet Gupta
 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.

I confirmed that your commit "ARC: dw2 unwind: don't force dwarf 2" is
indeed necessary to suppress the .debug_* sections when
CONFIG_DEBUG_INFO is off. But again, we're stripping .ko files anyways
before installing.

> I'm not planning to carry it and would prefer addressing the the root cause by
> removing the -gdwarf-2 toggle. I've added that and pushed rebased series. 
> Care to
> take it for a respin please.

I downloaded your latest commit
e47305af57d7eedc10b4720e604d669b10c69e3b and verified that stack
traces are properly displayed for code inside kernel modules as well
as vmlinux. I also called memcpy() on some bad address and got a
proper stack trace that involved memcpy().

I conclude that unwinding works for us.

Thank You
 Daniel

modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch to .eh_frame)

2016-09-22 Thread Vineet Gupta 
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

I'm not planning to carry it and would prefer addressing the the root cause by
removing the -gdwarf-2 toggle. I've added that and pushed rebased series. Care 
to
take it for a respin please.

Thx,
-Vineet

modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch to .eh_frame)

2016-09-22 Thread Vineet Gupta 
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

I'm not planning to carry it and would prefer addressing the the root cause by
removing the -gdwarf-2 toggle. I've added that and pushed rebased series. Care 
to
take it for a respin please.

Thx,
-Vineet