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


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

R.

> 
>> 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.
> 
> Cheers
>   Nick
> 
> 
> elf32-arm.c.patch
> 
> 
> 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
> 


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