This is the mail archive of the
mailing list for the GDB project.
Re: GDB for multiple targets
duane> [Are you describing additional items in "target.xml" that GDB
duane> [is this the place to add things? like cpu, arch, endian, etc]
daniel> We can add pretty much anything there that is useful.
daniel> already supported (<architecture>), or is that not sufficient? The
daniel> OSABI setting that Ulrich is referring to covers the bare metal / OS
daniel> distinction, too.
"Or is that not sufficient" - is the operative question.
(1) In the case of OpenOCD - nothing ensures the *openocd.cfg* file
matches what the *EXE*FILE* says and/or the actual hardware target found
via jtag. My goal wold be reporting up information so at a minimum some
warning message could be printed.
(2) In the arm micro controller "bare-metal-world" - the OSABI is often
not used or is generic, example: arm-elf - is a generic widely used
configuration that does not report the actual OS being used.
Example: If the "os-name" was reported up, and GDB knew about 'os-name'
- then 'os-name' threads could perhaps be supported.
(3) Today, OpenOCD reports "architecture=arm" - nothing more.
If the CPUNAME was reported up - other things could be done - for
example: ARM946 has an MMU and is armv5te, whereas other armv5te chips
(4) Chip Vendor Name, Family Name, and Specific Part Number - is not
Many embedded debuggers have the ability to display on-chip registers,
ie: The MicroChip IDE for PIC32 (a mips m4K cpu, via GCC) has displays
for UART, TIMERS, GPIO.
GDB Front Ends (ie: Eclipse, insight) could also display this type of
information - if - it had details about the chip.
(5) One other road block today - is while GDB can fetch this
information. I know of no command in GDB to pass the "target.xml" up the
food chain to the front end (ie: eclipse, insight)
Maybe a command like: "targetxmlfetch 'target.xml'" is needed?
(6) Same could be said about the "memorymap.xml"
None of us are *today* in the position to make all of these things
happen. Getting a few pieces in place would be very helpful so that
others can build upon them.
I have often badly desired those features. I have also seen GDB loose
out in discussions for the exact reason that it does not have the
ability to look at "chip-registers"
The problem is a chicken & egg problem, it is not in (A) because it is
not in (B), and not in (B) because (A) does not have it.
That said, and to that end - I think a target.xml report out of a "bare
metal" type debug target, with this sort of information would be very
... os foo specific details ...
The general "Robustness Principle" parse would be:
If it is not present, assume the value equals "unknown"
Know how to ignore sections you do not want or do not understand.
Pass everything up, others above you may understand what you do not.
This would allow target providers the ability to pass through, and up
information to the front end.