This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ARM mapping symbols and --strip-unneeded


Hi Nick,

thanks for getting back to me so quickly!

On Mon, Jun 27, 2016 at 11:57:54AM +0100, Nick Clifton wrote:

> > In the meaintime: Is there another way than --preserve-symbol= to tell
> > strip to preserve mapping symbols?
> If you are able to add command line options to the build system then you
> could try adding --no-strip-unneeded.  Alternatively you could add "@extra_stript_options"
> and then in the file extra_strip_options have --preserve-symbol=$a etc.
> That should avoid the shell processing problems.

I was able to hack -K \$a onto the command line and that seems to behave
as required. I'll try the @option_file workaround if it becomes
necessary - thanks for that!

Also, the build system already distinguishes file type "*SB
relocatable*" from "*SB executable*" and "*SB shared object*". So I am
able to add the -K options to the stripping of object files only. That
leaves the crt*.o intact but still produces nice, clean and small
executables and shared libraries - which from my understanding should be
all that's needed.

Still, I feel, strip rather than the package manager should know about
this special handling.

> As an alternative, you might like to try out the attached patch, which
> should prevent the mapping symbols from being stripped in the first place.
> Unfortunately this does have the drawback of making stripped big endian binaries
> bigger than their little endian counterparts.

The patch works fine. Thank you! But as you said, it applies to all
files, also leaving the mapping symbols in shared libraries and
executables, making them larger. When I add

	&& ((abfd->flags & (EXEC_P | DYNAMIC)) == 0)

to the selector, symbols are retained in the object files but stripped
from executables and shared libraries. Is that the correct way to go
about it? If so, I'd go ahead and open a bug with the extended patch as
you suggested.
-- 
thanks, Michael


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]