From: Nick Clifton <nickc@redhat.com>
To: Jan Beulich <JBeulich@novell.com>
Cc: binutils@sources.redhat.com
Subject: Re: stripping symbols needed for relocations
Date: Mon, 18 Oct 2004 14:19:00 -0000 [thread overview]
Message-ID: <4173D24F.1030407@redhat.com> (raw)
In-Reply-To: <s16e439a.026@emea1-mh.id2.novell.com>
Hi Jan,
> The --strip-all case is out of question, but my concern is primarily
> with the combination of --strip-symbol/--strip-symbols and -w, but to
> some degree also with the plain use of --strip-symbol/--strip-symbols:
> When trying to cut down the number of symbols in the linux kernel
> (subject to kallsyms lookup) I'm trying to eliminate all non-text
> symbols. Finding them is not a problem, but filtering out those used in
> relocations is, which is why I'd want objcopy to do this for me. Since
> I'm of the general opinion that --strip-symbol for symbols used in
> relocations for non-discarded sections (which I would hope already don't
> get the BSF_KEEP flag set) will result in a broken output file, I'd like
> to make objcopy smart enough to deal with that situation (possibly
> through a new option --keep-needed or --force-strip-needed, depending on
> what the desirable default would be and whether keeping the current
> behavior is a requirement).
OK - I see your point. My original thinking was that if the user had
specified --strip-symbol=foo on the objcopy command line then that meant
that they definitely wanted "foo" stripped out, even if it was used in a
reloc, and that they knew what they were doing.
Given that we are dealing with the binutils here, where you are allowed
to shoot yourself in the foot if you do not know what you are doing, I
think that this behaviour of the --strip-symbol switch should be
retained. I would have no objections however to a patch which added
another switch, say --strip-unused-symbol=<>, or indeed the
--keep-needed switch you suggested, in order to provide a safer
environment for stripping symbols.
Cheers
Nick
next parent reply other threads:[~2004-10-18 14:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <s16e439a.026@emea1-mh.id2.novell.com>
2004-10-18 14:19 ` Nick Clifton [this message]
2004-12-16 13:18 Jan Beulich
2004-12-16 14:20 ` Dave Korn
2004-12-16 15:48 ` Nick Clifton
-- strict thread matches above, loose matches on Subject: below --
2004-12-15 15:51 Jan Beulich
2004-12-16 12:07 ` Nick Clifton
2004-10-14 8:15 Jan Beulich
2004-10-11 11:48 Jan Beulich
2004-10-13 15:57 ` Nick Clifton
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=4173D24F.1030407@redhat.com \
--to=nickc@redhat.com \
--cc=JBeulich@novell.com \
--cc=binutils@sources.redhat.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).