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