This is the mail archive of the
mailing list for the binutils project.
Re: ARM mapping symbols and --strip-unneeded
- From: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- To: Nick Clifton <nickc at redhat dot com>, Michael Weiser <michael at weiser dot dinsnail dot net>, binutils at sourceware dot org
- Date: Mon, 27 Jun 2016 15:06:10 +0100
- Subject: Re: ARM mapping symbols and --strip-unneeded
- Authentication-results: sourceware.org; auth=none
- References: <20160626221336 dot GB1916 at weiser dot dinsnail dot net> <e7fff803-6244-4782-2768-6b301387aed8 at redhat dot com>
On 27/06/16 11:57, Nick Clifton wrote:
> Hi Michael,
>> So, is it reasonable to assume that ld relies on the mapping symbols
>> when producing output for big-endian ARM
> Yes. See bfd/elf32-arm.c:elf32_arm_write_section() for more details.
>> Based on this I'm wondering about the definition of "unneeded" (being:
>> "Remove all symbols that are not needed for relocation processing."):
>> Should the mapping symbols perhaps be considered needed and not
> For big-endian ARM binaries, yes.
And potentially for little-endian binaries as well. For example, they
might sometimes be needed to insert correct interworking veneers.
>> 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 would also argue that the build system is broken in that it is stripping
> files too early. But there is probably nothing that can be done about that).
> 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.
> If this patch does work for you, and you are unable to use any of the workarounds
> suggested above, then please could you open a bug report for this problem, so
> that we have somewhere to record the patch and the problem that it is fixing.
> diff --git a/bfd/elf32-arm.c b/bfd/elf32-arm.c
> index a7964c1..1380a04 100644
> --- a/bfd/elf32-arm.c
> +++ b/bfd/elf32-arm.c
> @@ -18266,6 +18266,25 @@ elf32_arm_copy_special_section_fields (const bfd *ibfd ATTRIBUTE_UNUSED,
> return FALSE;
> +/* If we are going to byteswap code then keep the mapping symbols. Without
> + this "strip --strip-unneeded" will remove them and that would prevent
> + stripped binaries from being byteswapped correctly. Unfortunately we do
> + not have access to link_info->globals->byteswap_code so we just test for
> + big endianness here. */
> +static void
> +elf32_arm_backend_symbol_processing (bfd *abfd, asymbol *sym)
> + if (bfd_big_endian (abfd)
> + && sym->name != NULL
> + && sym->section != bfd_abs_section_ptr
> + && (strcmp (sym->name, "$a") == 0
> + || strcmp (sym->name, "$t") == 0
> + || strcmp (sym->name, "$d") == 0))
> + sym->flags |= BSF_KEEP;
> +/* SPU ELF linker hash table. */
> #undef elf_backend_copy_special_section_fields
> #define elf_backend_copy_special_section_fields elf32_arm_copy_special_section_fields
> @@ -18324,6 +18343,7 @@ elf32_arm_copy_special_section_fields (const bfd *ibfd ATTRIBUTE_UNUSED,
> #define elf_backend_begin_write_processing elf32_arm_begin_write_processing
> #define elf_backend_add_symbol_hook elf32_arm_add_symbol_hook
> #define elf_backend_count_additional_relocs elf32_arm_count_additional_relocs
> +#define elf_backend_symbol_processing elf32_arm_backend_symbol_processing
> #define elf_backend_can_refcount 1
> #define elf_backend_can_gc_sections 1