public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
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

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