RFA: Skip ARM ELF Mapping symbols when showing disassembly

RFA: Skip ARM ELF Mapping symbols when showing disassembly

[Nick Clifton]

Hi Guys,

  I have recently committed a patch to the arm-elf port of GAS which
  causes it to generate special mapping symbols as required by the ARM
  ELF spec.  Unfortunately this now means that when GDB shows a
  disassembly it can select one of the mapping symbols instead of the
  proper function name symbol.

  The patch below is a fix for this problem.  It is not elegant, but
  it does have the advantage of being entirely arm specific.  A
  cleaner patch would require changes to generic code, which I did not
  feel comfortable doing.

  May I apply this patch ?

Cheers
        Nick

2003-11-13  Nick Clifton  <nickc@redhat.com>

	* arm-tdep.c (arm_elf_make_msymbol_special): Intercept arm-elf
	mapping symbols and artificially alter their value so that they
	are not used for disassembly displays.

Index: gdb/arm-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/arm-tdep.c,v
retrieving revision 1.155
diff -c -3 -p -r1.155 arm-tdep.c
*** gdb/arm-tdep.c	11 Nov 2003 20:04:52 -0000	1.155
--- gdb/arm-tdep.c	13 Nov 2003 14:27:49 -0000
*************** coff_sym_is_thumb (int val)
*** 2675,2680 ****
--- 2675,2692 ----
  static void
  arm_elf_make_msymbol_special(asymbol *sym, struct minimal_symbol *msym)
  {
+   /* FIXME: We want gdb to ignore the ARM ELF mapping symbols when
+      displaying disassembly so we use this horrible hack here to
+      artifically set their address to the highest possible value.
+      This is wrong of course, and it prevents the symbols from being
+      used for their intended purpose - to distinguish between ARM
+      and THUMB code.  So we ought to find a better way to do this.  */
+   if (bfd_asymbol_name (sym)
+       && bfd_asymbol_name (sym)[0] == '$'
+       && bfd_asymbol_name (sym)[1] != 0
+       && bfd_asymbol_name (sym)[2] == 0)
+     SYMBOL_VALUE_ADDRESS(msym) = (CORE_ADDR) 0x7ffffffc;
+       
    /* Thumb symbols are of type STT_LOPROC, (synonymous with
       STT_ARM_TFUNC).  */
    if (ELF_ST_TYPE (((elf_symbol_type *)sym)->internal_elf_sym.st_info)

Re: RFA: Skip ARM ELF Mapping symbols when showing disassembly

[Richard Earnshaw]

> Hi Guys,
> 
>   I have recently committed a patch to the arm-elf port of GAS which
>   causes it to generate special mapping symbols as required by the ARM
>   ELF spec.  Unfortunately this now means that when GDB shows a
>   disassembly it can select one of the mapping symbols instead of the
>   proper function name symbol.
> 
>   The patch below is a fix for this problem.  It is not elegant, but
>   it does have the advantage of being entirely arm specific.  A
>   cleaner patch would require changes to generic code, which I did not
>   feel comfortable doing.
> 
>   May I apply this patch ?
> 
> Cheers
>         Nick
> 

I wonder whether a better way to handle all this is to override 
slurp_symbol_table for arm-elf to a routine that just skips the mapping 
symbols entirely (or at least, doesn't put them into the list that it 
passes back to its caller), then to add a separate function to slurp the 
mapping symbols independently.  Then gdb and the disassembler (and the 
linker error reports) would all just work normally.

It would be necessary to add support for copying and fixing up the mapping 
symbols when linking, but that's probably not too hard.

R.

Re: RFA: Skip ARM ELF Mapping symbols when showing disassembly

[Daniel Jacobowitz]

On Thu, Nov 13, 2003 at 02:45:07PM +0000, Richard Earnshaw wrote:
> > Hi Guys,
> > 
> >   I have recently committed a patch to the arm-elf port of GAS which
> >   causes it to generate special mapping symbols as required by the ARM
> >   ELF spec.  Unfortunately this now means that when GDB shows a
> >   disassembly it can select one of the mapping symbols instead of the
> >   proper function name symbol.
> > 
> >   The patch below is a fix for this problem.  It is not elegant, but
> >   it does have the advantage of being entirely arm specific.  A
> >   cleaner patch would require changes to generic code, which I did not
> >   feel comfortable doing.
> > 
> >   May I apply this patch ?
> > 
> > Cheers
> >         Nick
> > 
> 
> I wonder whether a better way to handle all this is to override 
> slurp_symbol_table for arm-elf to a routine that just skips the mapping 
> symbols entirely (or at least, doesn't put them into the list that it 
> passes back to its caller), then to add a separate function to slurp the 
> mapping symbols independently.  Then gdb and the disassembler (and the 
> linker error reports) would all just work normally.
> 
> It would be necessary to add support for copying and fixing up the mapping 
> symbols when linking, but that's probably not too hard.

FWIW, I think this is a good idea.

I don't want to end up with them in the symbol table for GDB; there
could be a substantial number of them (especially if the linker emits
them for interworking veneers), and they could have nasty adverse
effects on the hash table.  Plus a symbol table isn't a useful data
structure for this information, I think, just a convenient way to store
it in the object file.

I have always envisioned this sort of information being carried by
.debug_line instead, but of course that doesn't meet the same needs as
the mapping symbols.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Skip ARM ELF Mapping symbols when showing disassembly

[Daniel Jacobowitz]

On Thu, Nov 13, 2003 at 02:45:07PM +0000, Richard Earnshaw wrote:
> > Hi Guys,
> > 
> >   I have recently committed a patch to the arm-elf port of GAS which
> >   causes it to generate special mapping symbols as required by the ARM
> >   ELF spec.  Unfortunately this now means that when GDB shows a
> >   disassembly it can select one of the mapping symbols instead of the
> >   proper function name symbol.
> > 
> >   The patch below is a fix for this problem.  It is not elegant, but
> >   it does have the advantage of being entirely arm specific.  A
> >   cleaner patch would require changes to generic code, which I did not
> >   feel comfortable doing.
> > 
> >   May I apply this patch ?
> > 
> > Cheers
> >         Nick
> > 
> 
> I wonder whether a better way to handle all this is to override 
> slurp_symbol_table for arm-elf to a routine that just skips the mapping 
> symbols entirely (or at least, doesn't put them into the list that it 
> passes back to its caller), then to add a separate function to slurp the 
> mapping symbols independently.  Then gdb and the disassembler (and the 
> linker error reports) would all just work normally.
> 
> It would be necessary to add support for copying and fixing up the mapping 
> symbols when linking, but that's probably not too hard.

Actually, I think it's not necessary, since elf_link_input_bfd doesn't
use the slurp routines anyway - it parses the ELF symbol table
directly.  In testing it appears to work.

There is another problem, though.  The symbols are in the symbol table
and thus have assigned numbers.  The returned list of symbols is passed
back to functions like bfd_canonicalize_reloc, which use the list of
symbols to resolve relocations.  Probably other consumers assume the
whole list of ELF symbols is returned, also, and index it by other
copies of the symbol index.  So the linker doesn't appear to care, but
objdump and possibly GDB do.

Any ideas on how to resolve this?  We can't NULL out the mapping
symbols in symptrs either, because the list is defined to be
NULL-terminated (even though we return its length...).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Skip ARM ELF Mapping symbols when showing disassembly

[Nick Clifton]

Hi Guys,

> Daniel Jacobowitz <drow@mvista.com> writes:

>> I wonder whether a better way to handle all this is to override 
>> slurp_symbol_table for arm-elf to a routine that just skips the mapping 
>> symbols entirely (or at least, doesn't put them into the list that it 
>> passes back to its caller), then to add a separate function to slurp the 
>> mapping symbols independently.  Then gdb and the disassembler (and the 
>> linker error reports) would all just work normally.
>> 
>> It would be necessary to add support for copying and fixing up the mapping 
>> symbols when linking, but that's probably not too hard.
>
> Actually, I think it's not necessary, since elf_link_input_bfd doesn't
> use the slurp routines anyway - it parses the ELF symbol table
> directly.  In testing it appears to work.
>
> There is another problem, though.  The symbols are in the symbol table
> and thus have assigned numbers.  The returned list of symbols is passed
> back to functions like bfd_canonicalize_reloc, which use the list of
> symbols to resolve relocations.  Probably other consumers assume the
> whole list of ELF symbols is returned, also, and index it by other
> copies of the symbol index.  So the linker doesn't appear to care, but
> objdump and possibly GDB do.
>
> Any ideas on how to resolve this?  We can't NULL out the mapping
> symbols in symptrs either, because the list is defined to be
> NULL-terminated (even though we return its length...).

How about providing a new BFD function which allows the caller to
determine if a symbol should be ignored ?  This function would call
through to an architecture specific backend routine if necessary,
although a generic routine which never ignored any symbols would be
the default.

We might even generalise the function to take a third argument (apart
from the bfd and the symbol) which is a bit-field defining the proposed
purpose(s) for the symbol and then have the function determine if it
is suitable.  ie something like this:

  enum { not_suitable; partially_suitable; fully_suitable } bfd_suitability;

  #define bfd_purpose_display (1 << 0)  /* Should the symbol be shown to the user ?  */
  #define bfd_purpose_resolve (1 << 1)  /* Should the symbol be used for resolving relocs ?  */
  
  extern bfd_suitability
  bfd_symbol_suits_purpose (bfd *         the_bfd,
                            bfd_symbol *  the_symbol,
                            unsigned      the_purposes);

Cheers
        Nick

Re: RFA: Skip ARM ELF Mapping symbols when showing disassembly

[Andrew Cagney]

Nick,

>   I have recently committed a patch to the arm-elf port of GAS which
>   causes it to generate special mapping symbols as required by the ARM
>   ELF spec.  Unfortunately this now means that when GDB shows a
>   disassembly it can select one of the mapping symbols instead of the
>   proper function name symbol.

(GDB has minimal (=== asymbol), partial and full symbols.  IN the below 
"symbol" refers to the minimal symbol.)

Hmm, what information do those mapping symbols provide?  Dig dig (from 
tc-arm.c) ...

       4.4.7 Mapping and tagging symbols

       A section of an ARM ELF file can contain a mixture of ARM code,
       Thumb code, and data.  There are inline transitions between code
       and data at literal pool boundaries. There can also be inline
       transitions between ARM code and Thumb code, for example in
       ARM-Thumb inter-working veneers.  Linkers, machine-level
       debuggers, profiling tools, and disassembly tools need to map
       images accurately. For example, setting an ARM breakpoint on a
       Thumb location, or in a literal pool, can crash the program
       being debugged, ruining the debugging session.

       ARM ELF entities are mapped (see section 4.4.7.1 below) and
       tagged (see section 4.4.7.2 below) using local symbols (with
       binding STB_LOCAL).  To assist consumers, mapping and tagging
       symbols should be collated first in the symbol table, before
       other symbols with binding STB_LOCAL.

       To allow properly collated mapping and tagging symbols to be
       skipped by consumers that have no interest in them, the first
       such symbol should have the name $m and its st_value field equal
       to the total number of mapping and tagging symbols (including
       the $m) in the symbol table.

       4.4.7.1 Mapping symbols

       $a    Labels the first byte of a sequence of ARM instructions.
             Its type is STT_FUNC.

       $d    Labels the first byte of a sequence of data items.
             Its type is STT_OBJECT.

       $t    Labels the first byte of a sequence of Thumb instructions.
             Its type is STT_FUNC.

       This list of mapping symbols may be extended in the future.

       Section-relative mapping symbols

       Mapping symbols defined in a section define a sequence of
       half-open address intervals that cover the address range of the
       section. Each interval starts at the address defined by a
       mapping symbol, and continues up to, but not including, the
       address defined by the next (in address order) mapping symbol or
       the end of the section. A corollary is that there must be a
       mapping symbol defined at the beginning of each section.
       Consumers can ignore the size of a section-relative mapping
       symbol. Producers can set it to 0.

       Absolute mapping symbols

       Because of the need to crystallize a Thumb address with the
       Thumb-bit set, absolute symbol of type STT_FUNC (symbols of type
       STT_FUNC defined in section SHN_ABS) need to be mapped with $a
       or $t.

       The extent of a mapping symbol defined in SHN_ABS is [st_value,
       st_value + st_size), or [st_value, st_value + 1) if st_size = 0,
       where [x, y) denotes the half-open address range from x,
       inclusive, to y, exclusive.

       In the absence of a mapping symbol, a consumer can interpret a
       function symbol with an odd value as the Thumb code address
       obtained by clearing the least significant bit of the
       value. This interpretation is deprecated, and it may not work in
       the future.

    Note - the Tagging symbols ($b, $f, $p $m) have been dropped from
    the EABI (which is still under development), so they are not
    implemented here.  */

So GDB and objdump both need this information?  How does objdump handle 
all this?

- should there be a BFD method that lets GDB better identify a user 
visibile [minimal] symbol (gdb's elf reader currently contains what can 
only be described as heuristics).

- should there be a BFD method that, given an address and symbol table, 
indicates the relevant ISA/ABI?

- or even just have BFD export name->addr and addr->name methods?

Andrew

Re: RFA: Skip ARM ELF Mapping symbols when showing disassembly

[Richard Earnshaw]

> Nick,
> 
> >   I have recently committed a patch to the arm-elf port of GAS which
> >   causes it to generate special mapping symbols as required by the ARM
> >   ELF spec.  Unfortunately this now means that when GDB shows a
> >   disassembly it can select one of the mapping symbols instead of the
> >   proper function name symbol.
> 
> (GDB has minimal (=== asymbol), partial and full symbols.  IN the below 
> "symbol" refers to the minimal symbol.)
> 
> Hmm, what information do those mapping symbols provide?  Dig dig (from 
> tc-arm.c) ...
> 
>        4.4.7 Mapping and tagging symbols
> 
>        A section of an ARM ELF file can contain a mixture of ARM code,
>        Thumb code, and data.  There are inline transitions between code
>        and data at literal pool boundaries. There can also be inline
>        transitions between ARM code and Thumb code, for example in
>        ARM-Thumb inter-working veneers.  Linkers, machine-level
>        debuggers, profiling tools, and disassembly tools need to map
>        images accurately. For example, setting an ARM breakpoint on a
>        Thumb location, or in a literal pool, can crash the program
>        being debugged, ruining the debugging session.
> 
>        ARM ELF entities are mapped (see section 4.4.7.1 below) and
>        tagged (see section 4.4.7.2 below) using local symbols (with
>        binding STB_LOCAL).  To assist consumers, mapping and tagging
>        symbols should be collated first in the symbol table, before
>        other symbols with binding STB_LOCAL.
> 
>        To allow properly collated mapping and tagging symbols to be
>        skipped by consumers that have no interest in them, the first
>        such symbol should have the name $m and its st_value field equal
>        to the total number of mapping and tagging symbols (including
>        the $m) in the symbol table.
> 
>        4.4.7.1 Mapping symbols
> 
>        $a    Labels the first byte of a sequence of ARM instructions.
>              Its type is STT_FUNC.
> 
>        $d    Labels the first byte of a sequence of data items.
>              Its type is STT_OBJECT.
> 
>        $t    Labels the first byte of a sequence of Thumb instructions.
>              Its type is STT_FUNC.
> 
>        This list of mapping symbols may be extended in the future.
> 
>        Section-relative mapping symbols
> 
>        Mapping symbols defined in a section define a sequence of
>        half-open address intervals that cover the address range of the
>        section. Each interval starts at the address defined by a
>        mapping symbol, and continues up to, but not including, the
>        address defined by the next (in address order) mapping symbol or
>        the end of the section. A corollary is that there must be a
>        mapping symbol defined at the beginning of each section.
>        Consumers can ignore the size of a section-relative mapping
>        symbol. Producers can set it to 0.
> 
>        Absolute mapping symbols
> 
>        Because of the need to crystallize a Thumb address with the
>        Thumb-bit set, absolute symbol of type STT_FUNC (symbols of type
>        STT_FUNC defined in section SHN_ABS) need to be mapped with $a
>        or $t.
> 
>        The extent of a mapping symbol defined in SHN_ABS is [st_value,
>        st_value + st_size), or [st_value, st_value + 1) if st_size = 0,
>        where [x, y) denotes the half-open address range from x,
>        inclusive, to y, exclusive.
> 
>        In the absence of a mapping symbol, a consumer can interpret a
>        function symbol with an odd value as the Thumb code address
>        obtained by clearing the least significant bit of the
>        value. This interpretation is deprecated, and it may not work in
>        the future.
> 
>     Note - the Tagging symbols ($b, $f, $p $m) have been dropped from
>     the EABI (which is still under development), so they are not
>     implemented here.  */
> 
> So GDB and objdump both need this information?  How does objdump handle 
> all this?
> 
> - should there be a BFD method that lets GDB better identify a user 
> visibile [minimal] symbol (gdb's elf reader currently contains what can 
> only be described as heuristics).
> 
> - should there be a BFD method that, given an address and symbol table, 
> indicates the relevant ISA/ABI?
> 
> - or even just have BFD export name->addr and addr->name methods?
> 
> Andrew
> 

The real question should be "what does gdb/objdump need to know?".  I 
think the answer to this is that it needs to know what is at a particular 
address in an image.  In other words, it needs to be asking "what type of 
object is at address X?"  How that information is stored in the image is 
not of particular interest outside of the BFD.  In particular, it 
shouldn't matter whether the information is stored in mapping symbols or 
some other  section in the object file.

So I think the bfd needs to export a bfd_map_address_to_type() interface 
that hides all the details of the representation behind it.  What's less 
clear is what types need to be returned, for ARM we really need to return 
something like BFD_OBJECT_DATA, BFD_OBJECT_ARM or BFD_OBJECT_THUMB, but it 
would vary from processor to processor.

R.

Re: RFA: Skip ARM ELF Mapping symbols when showing disassembly

[Andrew Cagney]

> So GDB and objdump both need this information?  How does objdump handle 
>> all this?
>> 
>> - should there be a BFD method that lets GDB better identify a user 
>> visibile [minimal] symbol (gdb's elf reader currently contains what can 
>> only be described as heuristics).
>> 
>> - should there be a BFD method that, given an address and symbol table, 
>> indicates the relevant ISA/ABI?
>> 
>> - or even just have BFD export name->addr and addr->name methods?
>> 
>> Andrew
>> 
> 
> 
> The real question should be "what does gdb/objdump need to know?".  I 
> think the answer to this is that it needs to know what is at a particular 
> address in an image.  In other words, it needs to be asking "what type of 
> object is at address X?"  How that information is stored in the image is 
> not of particular interest outside of the BFD.  In particular, it 
> shouldn't matter whether the information is stored in mapping symbols or 
> some other  section in the object file.
> 
> So I think the bfd needs to export a bfd_map_address_to_type() interface 
> that hides all the details of the representation behind it.  What's less 
> clear is what types need to be returned, for ARM we really need to return 
> something like BFD_OBJECT_DATA, BFD_OBJECT_ARM or BFD_OBJECT_THUMB, but it 
> would vary from processor to processor.

It's at this point, things get weird.

BFD hands GDB a raw symbol table (ignoring coff m'kay) and then GDB 
implements the search algorithm.  To implement a addr->attrib method, 
BFD's going to need a mechanism for searching GDB's symbol table and/or 
get at the underlying bfd symbol table.

That's why I mention the third one.  Throw the whole problem back at BFD 
:-)  Why does GDB even need a minimal symbol table anyway ....

Andrew

Re: RFA: Skip ARM ELF Mapping symbols when showing disassembly

[Richard Earnshaw]

> > So I think the bfd needs to export a bfd_map_address_to_type() interface 
> > that hides all the details of the representation behind it.  What's less 
> > clear is what types need to be returned, for ARM we really need to return 
> > something like BFD_OBJECT_DATA, BFD_OBJECT_ARM or BFD_OBJECT_THUMB, but it 
> > would vary from processor to processor.
> 
> It's at this point, things get weird.
> 
> BFD hands GDB a raw symbol table (ignoring coff m'kay) and then GDB 
> implements the search algorithm.  To implement a addr->attrib method, 
> BFD's going to need a mechanism for searching GDB's symbol table and/or 
> get at the underlying bfd symbol table.
> 

But it still gets the symbol table via a bfd method, most likely 
bfd_slurp_symbol_table.  On normal elf32 systems this is 
elf_slurp_symbol_table, but it doesn't have to be.  The comment in that 
file reads:

  /* Read each raw ELF symbol, converting from external ELF form to
     internal ELF form, and then using the information to create a
     canonical bfd symbol table entry.

     Note that we allocate the initial bfd canonical symbol buffer
     based on a one-to-one mapping of the ELF symbols to canonical
     symbols.  We actually use all the ELF symbols, so there will be no
     space left over at the end.  When we have all the symbols, we
     build the caller's pointer vector.  */

Note that the caller ends up using the pointer vector to iterate over the 
symbols.  What I'm suggesting is that on ARM, we replace 
elf_slurp_symbol_table with armelf_slurp_symbol_table, which does the same 
thing, but leaves the mapping symbols out of the caller's pointer vector.  
Any function using that routine will now see only real symbols; the 
mapping symbols have vanished entirely.

> That's why I mention the third one.  Throw the whole problem back at BFD 
> :-)  Why does GDB even need a minimal symbol table anyway ....
> 

Yep, that's another option.  GDB seems to be doing far too much mid-level 
symbol manipulation at present, which certainly suggests that the 
abstraction is wrong somewhere.

R.

Re: RFA: Skip ARM ELF Mapping symbols when showing disassembly

[Andrew Cagney]

>> It's at this point, things get weird.
>> 
>> BFD hands GDB a raw symbol table (ignoring coff m'kay) and then GDB 
>> implements the search algorithm.  To implement a addr->attrib method, 
>> BFD's going to need a mechanism for searching GDB's symbol table and/or 
>> get at the underlying bfd symbol table.
>> 
> 
> 
> But it still gets the symbol table via a bfd method, most likely 
> bfd_slurp_symbol_table.  On normal elf32 systems this is 
> elf_slurp_symbol_table, but it doesn't have to be.  The comment in that 
> file reads:
> 
>   /* Read each raw ELF symbol, converting from external ELF form to
>      internal ELF form, and then using the information to create a
>      canonical bfd symbol table entry.
> 
>      Note that we allocate the initial bfd canonical symbol buffer
>      based on a one-to-one mapping of the ELF symbols to canonical
>      symbols.  We actually use all the ELF symbols, so there will be no
>      space left over at the end.  When we have all the symbols, we
>      build the caller's pointer vector.  */


> Note that the caller ends up using the pointer vector to iterate over the 
> symbols.  What I'm suggesting is that on ARM, we replace 
> elf_slurp_symbol_table with armelf_slurp_symbol_table, which does the same 
> thing, but leaves the mapping symbols out of the caller's pointer vector.  
> Any function using that routine will now see only real symbols; the 
> mapping symbols have vanished entirely.

GDB still needs to hang onto the entire underling table so that the 
addr->type method has access to the information that it needs. 
Stripping that stuff out of the "pointer vector" would force GDB to 
slurp the table twice.  (BFD doesn't keep an internal pointer to this 
table around).

> Yep, that's another option.  GDB seems to be doing far too much mid-level 
> symbol manipulation at present, which certainly suggests that the 
> abstraction is wrong somewhere.

Andrew

Re: RFA: Skip ARM ELF Mapping symbols when showing disassembly

[Nick Clifton]

Hi Andrew,

> So GDB and objdump both need this information?  How does objdump
> handle all this?

Sorry - I am going to be away for the rest of this week - I'll get
back to this on Monday...

Cheers
        Nick
        

Re: RFA: Skip ARM ELF Mapping symbols when showing disassembly

[Nick Clifton]

Hi Andrew,

> Hmm, what information do those mapping symbols provide?  Dig dig (from
> tc-arm.c) ...
[snip]
> So GDB and objdump both need this information?

Well yes and no...

> How does objdump handle all this?

Apart from a hack to objdump to skip the mapping symbols when
displaying disassembly it does not use them.

Objdump (and gdb) both have perfectly adequate mechanisms for
distinguishing between code and data and between ARM and THUMB
instructions, so they do not need the mapping symbols.

The code to support mapping symbols in GAS was developed by ARM and I
accepted it because these symbols are required by the ARM ELF
specification.  [I believe that where possible, binutils should
attempt to follow all appropriate standards and specifications].  Note
- the patch is not a complete implementation of the specification
since the linker ought to generate these mapping symbols for its
arm<->thumb calling stubs.  Currently this has not been implemented.

So basically the mapping symbols are a distraction which gdb ought to
be able to ignore.  (Or use if it feels so minded, although as I say,
they are not fully implemented yet).


> - should there be a BFD method that lets GDB better identify a user
> visible [minimal] symbol (gdb's elf reader currently contains what
> can only be described as heuristics).

Yes - this would be a much cleaner way of handling this situation, and
presumably similar situations for other architectures which have
system type symbols which users are not supposed to see.


> - should there be a BFD method that, given an address and symbol
> table, indicates the relevant ISA/ABI?

Not sure.  Having such a method would be a good idea, but I am not
sure if it belongs in BFD or in OPCODES.  (Since opcodes already has
other disassembler related stuff).


> - or even just have BFD export name->addr and addr->name methods?

It already exports the bfd_asymbol_value() macro which can do
name->addr translation and the _bfd_find_nearest_line() function which
can do addr->name translation.  (Although it does not return a symbol
pointer).  Were you thinking of these or something else ?


Cheers
        Nick

Re: RFA: Skip ARM ELF Mapping symbols when showing disassembly

[Richard Earnshaw]

> Hi Andrew,
> 
> > Hmm, what information do those mapping symbols provide?  Dig dig (from
> > tc-arm.c) ...
> [snip]
> > So GDB and objdump both need this information?
> 
> Well yes and no...
> 
> > How does objdump handle all this?
> 
> Apart from a hack to objdump to skip the mapping symbols when
> displaying disassembly it does not use them.
> 

It should use them.  Then it can correctly disassemble data as data rather 
than instructions.

> Objdump (and gdb) both have perfectly adequate mechanisms for
> distinguishing between code and data and between ARM and THUMB
> instructions, so they do not need the mapping symbols.
> 

No they don't.  Try to disassemble a function that contains a mix of ARM 
and Thumb code and you will find that gdb/objdump just get it wrong.

For example:

	.code 16
	.thumb_func
	.align 0
	.global func
func:
	bx	pc
	nop
	.code 32
	bx	lr

which is disassembled as

a.out:     file format elf32-littlearm

Disassembly of section .text:

00000000 <func>:
   0:   4778            bx      pc
   2:   46c0            nop                     (mov r8, r8)
   4:   ff1e            second half of BL instruction 0xff1e
   6:   e12f            b       268 <func+0x268>


R.