Re: GDB for multiple targets

[Duane Ellis <duane@duaneellis.com>]

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">
   <architecture>arm</architecture>
   <cpuinfo>
           <arch>armv5tej</arch>
            <name>arm926ej-s</name>
   </cpuinfo>
   <osinfo name="foo">
        ... os foo specific details ...
   </osinfo>
   <interface>
        <type>jtag</type>
        <supplier>openocd</supplier>
        <version>r1181</version>
   </interface>
   <chipinfo>
      <mfgname>freescale</mfgname>
      <family>imx</family>
      <commonname>imx27</commonname>
      <partnumber>....</partnumber>
    </chipinfo>
</target>

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.

======================

-Duane.