Re: Re: 6502 support in GDB

["S. Champailler" <schampailler@skynet.be>]

Thx for your reply. It's very complete and, well, intimidating :-)
I'll think about it twice before starting :-/
Considering the time I spend actually debugging and the time
it'd take to update GDB, I'm afraid the balance is tilted on the
very wrong side.... unless it proves real fun to do...

Thank again for your time.

Stéphane


    ------ Message d'origine ------
    De: aburgess@redhat.com
    To: schampailler@skynet.be
Cc: gdb@sourceware.org
    Envoyé: vendredi 7 janvier 2022 11:43
    Objet: Re: 6502  support in GDB

          * S. Champailler via Gdb <gdb@sourceware.org> [2022-01-07 
10:36:39 +0100]:

  >
  > Hello,
  >
  >
  > I was wondering if it is "easy" to add support for a CPU in GDB.
  > Specifically the 6502.
  > I'm mostly interested in debugging some assembly code I have 
written. My use
  > case
  > is : I write some assembly, compile it, run it in an emulator and 
use GDB to
  > remote
  > connect to that emulator and do remote debugging.
  >
  > Before posting this I've checked the mailing list archives and the 
git
  > history and it seems
  > it has never been done before. I've read the documentation a bit and 
swa one
  > talks about
  > adding an architecture (wiki page of the "internals" manual). Is 
that the
  > right place to start ?
  >
  > I had a few questions:
  >
  > - how big an effort is it ? Are we talking about weeks, months ? I 
bet
  > months. This will
  > be a hobby project, so it has some chances of failing if it proves 
too hard
  > to do.

  If you've never worked on binutils-gdb before then its likely to take
  a while yes, as there's a lot you'll need to figure out, though asking
  specific questions is always a good idea.

  You can always look in the repository to see what was done when
  initial support for other architectures was added, for example in
  commit dbbb1059e62e9f I added initial RISC-V support to GDB, something
  like this might provide a starting point.

  However, the above commit was only the GDB side of things, you need to
  at a minimum teach bfd about your architecture, and, if you're only
  going to be debugging assembler, as you say below, you'll likely want
  a disassembler (that's in the opcodes directory).  There's lots of
  different approaches for writing the disassembler, some people make
  use of CGEN[1], but others just write their own from scratch.  It
  doesn't really matter, so long as you supply the disassembler API.

  If your existing assembler produces ELF files (or maybe other
  structured formats, though I know little about non-ELF) then you might
  want to teach bfd about how to read them for your architecture, then
  tools like objdump, objcopy, will work.  But I suspect you can
  probably skip that if you wanted, and just debug the image on the
  remote target, though you'd be stuck debugging by address - there's
  usually no debug information in a binary image.

  > - I understand I have to write a disassembler at the very least, is 
that
  > correct ?

  Discussed above.

  > - I understand I have to modify the emulator to provide a GDB remote 
access,
  > correct ?

  Yikes, that's a non-trivial task in itself.  The full remote protocol
  is documented here[2], it's probably worth a read before you start any
  work.  But you certainly don't need to implement everything to get
  something simple working.  There's a (not quite old) guide to writing
  gdbservers here[3] which includes some recommendations for which
  packets to start with.  Like I say, its pretty old, but could be worth
  a read.

  The other option would be to import your emulator into GDB.  GDB has a
  'target sim', see the sim/ directory.  This might be quicker if you
  have the emulator source.

  > - I've checked DWARF but I still don't get how to connect my ASM 
source to
  > the actual disassembly,
  >  does GDB provide help here ? (that is, when I'm pointing at my 
assembly
  > source code line,
  >  I'd like to know to which instruction it corresponds in the 6502 
code; same
  > stuff with symbols)

  GDB can consume the DWARF, but for creating the connection, that's the
  job of the assembler.

  Usually, in production tools based on the GNU stack, you'd use 'as'
  (see gas/ directory) to assemble your assembler files to ELF object
  files, then use 'ld' (see ld/ directory) to link them into a single
  ELF executable.  If you assemble with the -g flag you'll get debug
  information in DWARF format embedded in the final executable.

  For baremetal targets you often need a binary blob, so you'd use
  objcopy to pull the blob out of the ELF ready to load onto your
  target.  But, importantly, the addresses in the ELF would accurately
  reflect where the binary blob will be loaded, and so, the DWARF will
  correctly map addresses to lines.

  Now, GDB will read the DWARF (this is already handled, you'd need to
  make no changes), and can map things back to your assembler file.

  That said, there's nothing to stop GDB attaching to a remote target,
  disassembling memory, placing breakpoints (at addresses), and doing
  things like continue, or stepi, without any DWARF or ELF at all.

  I think your biggest hurdle will be deciding how you want GDB to
  interact with the target, neither approach is trivial.  Your choices
  seem to be add a gdbserver to your emulator, or port your emulator to
  the gdb simulator framework.

  Personally I'd probably go with the gdbserver approach, but I don't
  think there's a "wrong" answer.

  Not sure if any of the above actually helps at all,

  Good luck,
  Andrew

  [1] https://sourceware.org/cgen/
  [2] https://sourceware.org/gdb/onlinedocs/gdb/Remote-Protocol.html
  [3] 
https://www.embecosm.com/appnotes/ean4/embecosm-howto-rsp-server-ean4-issue-2.html