Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Richard Earnshaw <rearnsha@arm.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: Richard.Earnshaw@arm.com, Nick Clifton <nickc@redhat.com>,
	gdb-patches@sources.redhat.com, binutils@sources.redhat.com
Subject: Re: RFA: Skip ARM ELF Mapping symbols when showing disassembly
Date: Tue, 18 Nov 2003 17:29:00 -0000	[thread overview]
Message-ID: <200311181729.hAIHTQN14174@pc960.cambridge.arm.com> (raw)
In-Reply-To: Your message of "Tue, 18 Nov 2003 12:20:10 EST." <3FBA54CA.3080900@redhat.com>

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


  reply	other threads:[~2003-11-18 17:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-13 14:29 Nick Clifton
2003-11-13 14:45 ` Richard Earnshaw
2003-11-13 15:20   ` Daniel Jacobowitz
2004-01-14 23:42   ` Daniel Jacobowitz
2004-01-20 13:23     ` Nick Clifton
2003-11-18 16:15 ` Andrew Cagney
2003-11-18 16:45   ` Richard Earnshaw
2003-11-18 17:20     ` Andrew Cagney
2003-11-18 17:29       ` Richard Earnshaw [this message]
2003-11-18 17:41         ` Andrew Cagney
2003-11-18 19:55   ` Nick Clifton
2003-11-25 12:25   ` Nick Clifton
2003-11-25 12:34     ` Richard Earnshaw

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200311181729.hAIHTQN14174@pc960.cambridge.arm.com \
    --to=rearnsha@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=ac131313@redhat.com \
    --cc=binutils@sources.redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=nickc@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox