This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 various ways

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

- 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
(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?)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]