This is the mail archive of the gdb-prs@sources.redhat.com 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]

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:


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