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]

Re: GDB for multiple targets

duane> [Are you describing additional items in "target.xml" that GDB requests]

daniel> [yes]

duane> [is this the place to add things? like cpu, arch, endian, etc]

daniel> We can add pretty much anything there that is useful. Architecture is
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 have MMUs...

(4) Chip Vendor Name, Family Name, and Specific Part Number - is not presently reported.

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 helpful:

<target version="1.0">
  <osinfo name="foo">
       ... 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.



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