This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
pending/1385: GDB and opcodes
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: gdb-gnats at sources dot redhat dot com
- Date: Wed, 03 Sep 2003 19:39:58 -0400
- Subject: pending/1385: GDB and opcodes
>Number: 1385
>Category: pending
>Synopsis: GDB and opcodes
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: change-request
>Submitter-Id: unknown
>Arrival-Date: Sat Sep 20 19:28:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:
>Release:
>Organization:
>Environment:
>Description:
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
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: