[Buildroot] Stripping kernel modules for ARC

[Buildroot] Stripping kernel modules for ARC

[Alexey Brodkin]

Hello,

This is a follow-up of discussion started here
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/86

The problem in hand is kernel stack unwinding on ARC historically was done
with use of debug_frame instead of more common eh_frame. And if stripping
of target binaries is enabled in Buildroot invocation of strip with
"--strip-unneeded" gets rid of debug_frame section effectively making
kernel unwinder helpless.

I'm wondering what would be a better way to strip modules on ARC in Buildroot?

I may see at least following solutions:
?1. Empty STRIP_STRIP_UNNEEDED or even KSTRIPCMD for ARC
? ? This together with?http://lists.infradead.org/pipermail/linux-snps-arc/2016-September/001483.html
? ? will still produce pretty compact .ko files on target
?2. Use objdump instead of strip with explicitly mentioned sections to keep or remove

Any thoughts are much appreciated.

-Alexey

[Buildroot] Stripping kernel modules for ARC

[Arnout Vandecappelle]

On 14-09-16 13:29, Alexey Brodkin wrote:
> Hello,
>
> This is a follow-up of discussion started here
> https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/86
>
> The problem in hand is kernel stack unwinding on ARC historically was done
> with use of debug_frame instead of more common eh_frame. And if stripping
> of target binaries is enabled in Buildroot invocation of strip with
> "--strip-unneeded" gets rid of debug_frame section effectively making
> kernel unwinder helpless.
>
> I'm wondering what would be a better way to strip modules on ARC in Buildroot?
>
> I may see at least following solutions:
>  1. Empty STRIP_STRIP_UNNEEDED or even KSTRIPCMD for ARC
>     This together with
> http://lists.infradead.org/pipermail/linux-snps-arc/2016-September/001483.html
>     will still produce pretty compact .ko files on target

 How about using --keep-symbol to keep the debug_frame? Or is it not a symbol?

>  2. Use objdump instead of strip with explicitly mentioned sections to keep or
> remove
 strip also has --remove-section.

 Regards,
 Arnout


>
> Any thoughts are much appreciated.
>
> -Alexey
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>

-- 
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Stripping kernel modules for ARC

[Vineet Gupta]

On 09/14/2016 04:29 AM, Alexey Brodkin wrote:
> Hello,
> 
> This is a follow-up of discussion started here
> https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/86
> 
> The problem in hand is kernel stack unwinding on ARC historically was done
> with use of debug_frame instead of more common eh_frame. 

Just for the record, I will be switching kernel unwinder to .eh_frame anyways -
it's just taking longer than I hoped to. So there is no need to do anything
special for .debug_frame - not as of now.

The question is if we enable BR2_STRIP_NONE=y in buildroot, what strip is run
on kernel / modules. And also does it strip build and target/install modules
differently such that target ones are stripped, but not those for debugging etc.

-Vineet

> And if stripping
> of target binaries is enabled in Buildroot invocation of strip with
> "--strip-unneeded" gets rid of debug_frame section effectively making
> kernel unwinder helpless.
> 
> I'm wondering what would be a better way to strip modules on ARC in Buildroot?
> 
> I may see at least following solutions:
>  1. Empty STRIP_STRIP_UNNEEDED or even KSTRIPCMD for ARC
>     This together with http://lists.infradead.org/pipermail/linux-snps-arc/2016-September/001483.html
>     will still produce pretty compact .ko files on target
>  2. Use objdump instead of strip with explicitly mentioned sections to keep or remove
> 
> Any thoughts are much appreciated.
> 
> -Alexey
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 

[Buildroot] Stripping kernel modules for ARC

[Peter Korsgaard]

>>>>> "Vineet" == Vineet Gupta <vgupta@synopsys.com> writes:

 > On 09/14/2016 04:29 AM, Alexey Brodkin wrote:
 >> Hello,
 >> 
 >> This is a follow-up of discussion started here
 >> https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/86
 >> 
 >> The problem in hand is kernel stack unwinding on ARC historically was done
 >> with use of debug_frame instead of more common eh_frame. 

 > Just for the record, I will be switching kernel unwinder to .eh_frame anyways -
 > it's just taking longer than I hoped to. So there is no need to do anything
 > special for .debug_frame - not as of now.

Ok, what kind of time frame are we looking at? Within the 2016.11 cycle
or longer?


 > The question is if we enable BR2_STRIP_NONE=y in buildroot, what strip is run
 > on kernel / modules. And also does it strip build and target/install modules
 > differently such that target ones are stripped, but not those for debugging etc.

git grep -A3 STRIP_none package/Makefile.in
package/Makefile.in:ifeq ($(BR2_STRIP_none),y)
package/Makefile.in-TARGET_STRIP = true
package/Makefile.in-STRIPCMD = $(TARGET_STRIP)
package/Makefile.in-KSTRIPCMD = $(TARGET_STRIP)

So the stripping in target-finalize becomes a NOP when BR2_STRIP_none is
selected.

-- 
Bye, Peter Korsgaard

[Buildroot] Stripping kernel modules for ARC

[Alexey Brodkin]

Hi Vineet,

On Wed, 2016-09-14 at 21:57 +0200, Peter Korsgaard wrote:
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > "Vineet" == Vineet Gupta <vgupta@synopsys.com> writes:
> 
> ?> On 09/14/2016 04:29 AM, Alexey Brodkin wrote:
> ?>> Hello,
> ?>>?
> ?>> This is a follow-up of discussion started here
> ?>> https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/86
> ?>>?
> ?>> The problem in hand is kernel stack unwinding on ARC historically was done
> ?>> with use of debug_frame instead of more common eh_frame.?
> 
> ?> Just for the record, I will be switching kernel unwinder to .eh_frame anyways -
> ?> it's just taking longer than I hoped to. So there is no need to do anything
> ?> special for .debug_frame - not as of now.
> 
> Ok, what kind of time frame are we looking at? Within the 2016.11 cycle
> or longer?
> 
> 
> ?> The question is if we enable BR2_STRIP_NONE=y in buildroot, what strip is run
> ?> on kernel / modules. And also does it strip build and target/install modules
> ?> differently such that target ones are stripped, but not those for debugging etc.
> 
> git grep -A3 STRIP_none package/Makefile.in
> package/Makefile.in:ifeq ($(BR2_STRIP_none),y)
> package/Makefile.in-TARGET_STRIP = true
> package/Makefile.in-STRIPCMD = $(TARGET_STRIP)
> package/Makefile.in-KSTRIPCMD = $(TARGET_STRIP)
> 
> So the stripping in target-finalize becomes a NOP when BR2_STRIP_none is
> selected.

Just to add buildroot doesn't do any stripping in "output/build/XXX" at all.
And depending on BR2_STRIP_xxx binaries in "output/target" folder could be stripped.
And different binaries could be stripped differently, this in particular is appled
to kernel modules (thus KSTRIPCMD is used along with normal STRIPCMD).

-Alexey

[Buildroot] Stripping kernel modules for ARC

[Vineet Gupta]

On 09/14/2016 12:57 PM, Peter Korsgaard wrote:
>  >> The problem in hand is kernel stack unwinding on ARC historically was done
>  >> with use of debug_frame instead of more common eh_frame. 
> 
>  > Just for the record, I will be switching kernel unwinder to .eh_frame anyways -
>  > it's just taking longer than I hoped to. So there is no need to do anything
>  > special for .debug_frame - not as of now.
> 
> Ok, what kind of time frame are we looking at? Within the 2016.11 cycle
> or longer?

What kernel will this BR release be. My changes will go into 4.9.

-Vineet

[Buildroot] Stripping kernel modules for ARC

[Peter Korsgaard]

>>>>> "Vineet" == Vineet Gupta <vgupta@synopsys.com> writes:

Hi,

 >> Ok, what kind of time frame are we looking at? Within the 2016.11 cycle
 >> or longer?

 > What kernel will this BR release be. My changes will go into 4.9.

Ok. Whatever is latest stable by the time 2016.11-rc1 gets released -
E.G. presumably 4.8.

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] Stripping kernel modules for ARC

[Thomas Petazzoni]

Hello,

On Wed, 14 Sep 2016 14:29:35 -0700, Daniel Mentz wrote:

> I believe there might be a third option where we pass INSTALL_MOD_STRIP=1
> to the kernel Makefile when running "make modules_install". It would then
> require a change in the Linux kernel Makefile to run a different
> strip/objcopy command for ARC. This would contain the details of stripping
> .ko files to the Linux kernel build system. Otherwise, we'll have this
> cross-dependency between the kernel and buildroot. As soon as the kernel
> switches to .eh_frame, buildroot would have to change again.

Exactly my thinking. I discovered INSTALL_MOD_STRIP only recently, and
I believe we should use it for the kernel instead of having our own
logic. This would remove the need for special logic in Buildroot to
strip kernel modules, and would leave it to the kernel build system to
know how modules should be stripped in an architecture-specific way.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] Stripping kernel modules for ARC

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Hello,
 > On Wed, 14 Sep 2016 14:29:35 -0700, Daniel Mentz wrote:

 >> I believe there might be a third option where we pass INSTALL_MOD_STRIP=1
 >> to the kernel Makefile when running "make modules_install". It would then
 >> require a change in the Linux kernel Makefile to run a different
 >> strip/objcopy command for ARC. This would contain the details of stripping
 >> .ko files to the Linux kernel build system. Otherwise, we'll have this
 >> cross-dependency between the kernel and buildroot. As soon as the kernel
 >> switches to .eh_frame, buildroot would have to change again.

 > Exactly my thinking. I discovered INSTALL_MOD_STRIP only recently, and
 > I believe we should use it for the kernel instead of having our own
 > logic. This would remove the need for special logic in Buildroot to
 > strip kernel modules, and would leave it to the kernel build system to
 > know how modules should be stripped in an architecture-specific way.

Sounds good. When was this introduced and what about external kernel modules?

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] Stripping kernel modules for ARC

[Thomas Petazzoni]

Hello,

On Thu, 15 Sep 2016 09:18:58 +0200, Peter Korsgaard wrote:

> Sounds good. When was this introduced and what about external kernel modules?

Introduced in commit ac031f26e89cc04fc7504f31ae137857eb83a051, appeared
first in 2.6.18.

External kernel modules: the one using kbuild will do fine, as long as
we use the modules_install target of the kbuild build system and not
manually install/copy the .ko files.

External kernel modules not using kbuild would obviously no longer be
stripped. Not sure how many of these we have today, and how to handle
them. They could be problematic :-/

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] Stripping kernel modules for ARC

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Hello,
 > On Thu, 15 Sep 2016 09:18:58 +0200, Peter Korsgaard wrote:

 >> Sounds good. When was this introduced and what about external kernel modules?

 > Introduced in commit ac031f26e89cc04fc7504f31ae137857eb83a051, appeared
 > first in 2.6.18.

Ok, good!

 > External kernel modules: the one using kbuild will do fine, as long as
 > we use the modules_install target of the kbuild build system and not
 > manually install/copy the .ko files.

 > External kernel modules not using kbuild would obviously no longer be
 > stripped. Not sure how many of these we have today, and how to handle
 > them. They could be problematic :-/

I guess we'll just have to handle those explictly whenever we find them.

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] Stripping kernel modules for ARC

[Alexey Brodkin]

Hi all,

On Thu, 2016-09-15 at 10:08 +0200, Peter Korsgaard wrote:
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> 
> ?> Hello,
> ?> On Thu, 15 Sep 2016 09:18:58 +0200, Peter Korsgaard wrote:
> 
> ?>> Sounds good. When was this introduced and what about external kernel modules?
> 
> ?> Introduced in commit ac031f26e89cc04fc7504f31ae137857eb83a051, appeared
> ?> first in 2.6.18.
> 
> Ok, good!
> 
> ?> External kernel modules: the one using kbuild will do fine, as long as
> ?> we use the modules_install target of the kbuild build system and not
> ?> manually install/copy the .ko files.
> 
> ?> External kernel modules not using kbuild would obviously no longer be
> ?> stripped. Not sure how many of these we have today, and how to handle
> ?> them. They could be problematic :-/
> 
> I guess we'll just have to handle those explictly whenever we find them.

Let me cook up a patch which uses?INSTALL_MOD_STRIP=1 then.

-Alexey