GDB and opcodes

[Andrew Cagney <ac131313 at redhat dot com>]

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

- 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?)
enjoy,
Andrew