This is the mail archive of the
mailing list for the GDB project.
GDB and opcodes
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: binutils at sources dot redhat dot com, gdb at sources dot redhat dot com
- Date: Wed, 03 Sep 2003 19:39:58 -0400
- Subject: GDB and opcodes
Some notes from my recent cleanup and the comments it received:
- I suspect that "moving forward" a vfprintf, instead of fprintf,
signatured output function would be better - easier to wrap it up in
- what are the memory allocation rules for the disassembler info struct?
GDB could easily be leaking memory.
- what about multiple disassemblers?
GDB with multi-arch is going to want multiple disassemblers active
- access to the disassembler option table?
(has come up before) GDB would like to add a more generic "set
disassembler <tab>" command so that there is a command that roughly
corresponds to the objdump disassembler option.
- access to the assembler?
GDB would like to support a mechanism like:
(gdb) assemble 0x1000
> move r1, r2
> store r2, foo
- some assemblers assume a BFD (m68hc11 comes to mind)
GDB may not have a BFD handy :-/ GDB can find itself talking to a random
architectured target vis:
(gdb) set architecture romp
(gdb) target remote romp:123
(gdb) x/i $pc
- access to address -> arch/mach map?
There's a bfd -> disassembler map, but underneath that there must be
some kind of ADDRESS -> arch/mach map. GDB would like access to it.
Firstly so that it can better handle disassembly where the machine
switches mode midstream (as in sh/sh64, mips/mips16, ia64/ia32,
ia32/amd64, ...) (GDB may not even have a BFD) and secondly so that it
can know things like the correct breakpoint to insert. Since
OPCODES/BFD must already be doing this, gdb would like to share :-)
(now what have I forgotten?)