Re: 6502 support in GDB

* S. Champailler via Gdb <[email protected]> [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