From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
To: buildroot@busybox.net
Subject: [Buildroot] Stripping kernel modules for ARC
Date: Wed, 14 Sep 2016 20:00:27 +0000 [thread overview]
Message-ID: <1473883226.3994.7.camel@synopsys.com> (raw)
In-Reply-To: <87mvjafe5t.fsf@dell.be.48ers.dk>
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
next prev parent reply other threads:[~2016-09-14 20:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-14 11:29 [Buildroot] Stripping kernel modules for ARC Alexey Brodkin
2016-09-14 19:00 ` Arnout Vandecappelle
2016-09-14 19:18 ` Vineet Gupta
2016-09-14 19:57 ` Peter Korsgaard
2016-09-14 20:00 ` Alexey Brodkin [this message]
2016-09-14 20:18 ` Vineet Gupta
2016-09-14 20:21 ` Peter Korsgaard
[not found] ` <CAE2F3rCBwysRFrMf4CD6uLevvfw0TNaZGyptOj6MLDQvGPPwFg@mail.gmail.com>
2016-09-15 6:47 ` Thomas Petazzoni
2016-09-15 7:18 ` Peter Korsgaard
2016-09-15 7:49 ` Thomas Petazzoni
2016-09-15 8:08 ` Peter Korsgaard
2016-09-15 10:53 ` Alexey Brodkin
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=1473883226.3994.7.camel@synopsys.com \
--to=alexey.brodkin@synopsys.com \
--cc=buildroot@busybox.net \
/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