Re: [PATCH] Fix type and alignment of ARM/Thumb EABI mapping symbols

[Richard Earnshaw <rearnsha@gcc.gnu.org>]

On Sun, 2005-03-27 at 21:25, Julian Brown wrote:
> Hi,
> 
> This patch fixes two problems: the type of mapping symbols is made 
> STT_NOTYPE (from STT_FUNC or STT_OBJECT from ARM/Thumb or data 
> respectively), and the alignment is corrected to not have the low bit 
> set for Thumb mapping symbols, in accordance with the latest version of 
> the ARM AAELF spec.
> 
> Unfortunately altering the symbol type to STT_NOTYPE for mapping symbols 
> affects the output of disassembly from objdump. $a and $t were 
> previously treated as functions. When objdump tried to find the closest 
> symbol for possibly-symbol-relative offsets previously, it found those 
> mapping symbols since compare_symbols places functions first in a sorted 
> version of the symbol table. They were then rejected by the 
> symbol_is_valid hook (arm_symbol_is_valid) from the disassemble_info 
> struct, and the section name was printed instead.
> 
> When the type of mapping symbols is changed to STT_NOTYPE, they are no 
> longer placed first in the sorted symbol list, so another symbol is used 
> instead. This causes test regressions, e.g. a symbol-offset address 
> which was previously output as:
> 
>    bl      8224 <.text-0xc>
> 
> was output instead as:
> 
>    bl      8224 <_start-0xc>
> 
> In the interest of preserving existing behaviour, I have fixed this by 
> adding a new disassemble_info hook which allows the symbol table used 
> for disassembly to have a target-specific hook for altering each symbol 
> (or remove it) in the remove_useless_symbols function. This sets the 
> BSF_FUNCTION flag for mapping symbols, which makes things behave the way 
> they used to, and possibly provides useful functionality for other 
> platforms as well.
> 
> It may be better to just change the expected test output instead. Thoughts?
> 

I think the tests should be fixed.  Other targets (those that don't have
mapping symbols) would almost certainly output _start in the example
above, so the existing behaviour should be considered undesirable at
best and probably just buggy.

That should allow you to simplify your patch so that you don't need to
touch MI parts.

R.