Re: GDB for multiple targets

Re: GDB for multiple targets

[Duane Ellis]

mark khouzam> [gdb for multiple targets]

michael snyder> We could set up a query as part of the initial
michael snyder> "target remote" handshake. It would be nice
michael snyder> to have a standard agreed-upon before
michael snyder> implementation.

ulrich> Hmm, GDB already detects the target automatically, using 
the"target description" mechanism.

I am one of the "elfs" that work on OpenOCD (the GDB + JTAG + ARM debug 
package)

Are you describing additional items in "target.xml" that GDB requests 
from the remote?

If so - what about other items, such as target endian, cputype (or in 
arm terms, "arch") and perhaps a flag that indicates the target is "bare 
metal" and not an operating system based target?

-Duane.

Re: GDB for multiple targets

[Daniel Jacobowitz]

On Mon, Nov 24, 2008 at 11:34:22AM -0500, Duane Ellis wrote:
> Are you describing additional items in "target.xml" that GDB requests  
> from the remote?

Right.

> If so - what about other items, such as target endian, cputype (or in arm 
> terms, "arch") and perhaps a flag that indicates the target is "bare  
> metal" and not an operating system based target?

We can add pretty much anything there that is useful.  Architecture is
already supported (<architecture>), or is that not sufficient?  The
OSABI setting that Ulrich is referring to covers the bare metal / OS
distinction, too.

Endianness is not currently present but would be an easy addition.
I haven't bothered, because in most cases you have an executable file;
that doesn't tell you the CPU arch, but it does tell you the
endianness.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB for multiple targets

[Duane Ellis]

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.

Re: GDB for multiple targets

[Daniel Jacobowitz]

On Mon, Nov 24, 2008 at 07:03:37PM -0500, Duane Ellis wrote:
> (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.

Yes, we already do generate such warnings.  You have to generate an
architecture element in the description to get that behavior though.

> (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.

arm-elf is not an OSABI, it's a target triplet.  The usual OSABI for
it is "none".  GDB doesn't support dynamic registration of new OSABIs,
but it could probably be implemented.

> 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.

The way to do this is not by chip name but by the rest of the target
description language.  We're already doing that at CodeSourcery.

> (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"

Right.  Patches welcome.

> None of us are *today* in the position to make all of these things  
> happen.

I beg to differ.  There's no chicken and egg problem.  I and others
have spent the past several years adding this sort of feature to GDB
for the same reasons you describe and we're already doing things with
GDB that the GDB of several years ago couldn't come close to.

When you need things that we haven't added already, you're more than
welcome to contribute :-) But please see about an FSF copyright
assignment if you plan to do that; I can help you with that if you
don't have one yet.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB for multiple targets

[Duane Ellis]

duane>Many embedded debuggers have the ability to display on-chip 
registers,  [snip]

daniel>  The way to do this is not by chip name but by the rest of the 
target description language. We're already doing that at CodeSourcery.

Is this "target description language" documented somewhere? I have not 
heard nor seen this.

-Duane.

Re: GDB for multiple targets

[Daniel Jacobowitz]

On Tue, Nov 25, 2008 at 12:47:35PM -0500, Duane Ellis wrote:
> duane>Many embedded debuggers have the ability to display on-chip  
> registers,  [snip]
>
> daniel>  The way to do this is not by chip name but by the rest of the  
> target description language. We're already doing that at CodeSourcery.
>
> Is this "target description language" documented somewhere? I have not  
> heard nor seen this.

This is exactly the same XML descriptions we've been talking about;
it's got a section in the GDB manual.

-- 
Daniel Jacobowitz
CodeSourcery

GDB for multiple targets

[Marc Khouzam]

Hi,
 
I would like to have one GDB binary on Linux to debug different targets:
Linux and Dicos.
I built GDB with --enable-targets=i686-ericsson-dicos so I get Linux by
default, and Dicos as a possibility.
 
From what I understand, to debug a Dicos target, I need 'set osabi
DICOS'
 
I'm trying to find out how difficult it would be (if at all possible),
for GDB to, instead, automatically
detect the target after a 'target remote' command.
 
The reason for this is to have the DSF-GDB frontend simply be able to
connect to a target, without
requiring the user to specify which type.
 
Is it possible?
 
Thanks
 
Marc
 

Re: GDB for multiple targets

[Michael Snyder]

Marc Khouzam wrote:
> Hi,
>  
> I would like to have one GDB binary on Linux to debug different targets:
> Linux and Dicos.
> I built GDB with --enable-targets=i686-ericsson-dicos so I get Linux by
> default, and Dicos as a possibility.
>  
> From what I understand, to debug a Dicos target, I need 'set osabi
> DICOS'
>  
> I'm trying to find out how difficult it would be (if at all possible),
> for GDB to, instead, automatically
> detect the target after a 'target remote' command.
>  
> The reason for this is to have the DSF-GDB frontend simply be able to
> connect to a target, without
> requiring the user to specify which type.
>  
> Is it possible?

We could set up a query as part of the initial "target remote" 
handshake.  It would be nice to have a standard agreed-upon before
implementation.

Re: GDB for multiple targets

[Ulrich Weigand]

Michael Snyder wrote:
> Marc Khouzam wrote:
> > From what I understand, to debug a Dicos target, I need 'set osabi
> > DICOS'
> >  
> > I'm trying to find out how difficult it would be (if at all possible),
> > for GDB to, instead, automatically
> > detect the target after a 'target remote' command.
> >  
> > The reason for this is to have the DSF-GDB frontend simply be able to
> > connect to a target, without
> > requiring the user to specify which type.
> >  
> > Is it possible?
> 
> We could set up a query as part of the initial "target remote" 
> handshake.  It would be nice to have a standard agreed-upon before
> implementation.

Hmm, GDB already detects the target automatically, using the
"target description" mechanism.  However, this currently sets
only the architecture, not the osabi, and in the particular
case described above, both host and target *architectures* are
the same, but just the osabi differs ...

I think it would make sense to have the target description
provide the proper osabi setting as well (maybe using the
existing "properties" mechanism), and have GDB default to
the osabi in the target description.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

RE: GDB for multiple targets

[Marc Khouzam]

 

> From: Ulrich Weigand [mailto:uweigand@de.ibm.com] 
> Sent: Saturday, November 22, 2008 10:25 AM
>
> Michael Snyder wrote:
> > Marc Khouzam wrote:
> > > From what I understand, to debug a Dicos target, I need 'set osabi
> > > DICOS'
> > >  
> > > I'm trying to find out how difficult it would be (if at 
> all possible),
> > > for GDB to, instead, automatically
> > > detect the target after a 'target remote' command.
> > >  
> > > The reason for this is to have the DSF-GDB frontend 
> simply be able to
> > > connect to a target, without
> > > requiring the user to specify which type.
> > >  
> > > Is it possible?
> > 
> > We could set up a query as part of the initial "target remote" 
> > handshake.  It would be nice to have a standard agreed-upon before
> > implementation.
> 
> Hmm, GDB already detects the target automatically, using the
> "target description" mechanism.  However, this currently sets
> only the architecture, not the osabi, and in the particular
> case described above, both host and target *architectures* are
> the same, but just the osabi differs ...
> 
> I think it would make sense to have the target description
> provide the proper osabi setting as well (maybe using the
> existing "properties" mechanism), and have GDB default to
> the osabi in the target description.

Thanks Ulrich and sorry for the late reply.

What we are hoping for is to use the same GDB binary on a host
to debug many different targets such as:
x86 Linux and non-linux
powerPC linux and non-linux
powerPC Linux and x86 non-linux
...
Emulator e.g. QEMU, Simics, 

From what has been said, I believe this is possible, as long as 
the user specifies the osabi using the 'set oasbi' command.
If the osabi was automatically set by GDB, as you suggest above,
is there anything else to worry about to allow the
same GDB binary to be able to automatically be ready to debug the
many different targets above?

Thanks again

Marc

Re: GDB for multiple targets

[Ulrich Weigand]

Marc Khouzam wrote:

> What we are hoping for is to use the same GDB binary on a host
> to debug many different targets such as:
> x86 Linux and non-linux
> powerPC linux and non-linux
> powerPC Linux and x86 non-linux
> ...
> Emulator e.g. QEMU, Simics,

Yes, it was certainly the intent that the --enable-targets options
should make such a use case possible.

> From what has been said, I believe this is possible, as long as
> the user specifies the osabi using the 'set oasbi' command.
> If the osabi was automatically set by GDB, as you suggest above,
> is there anything else to worry about to allow the
> same GDB binary to be able to automatically be ready to debug the
> many different targets above?

Except for the target architecture (which is already provided as
part of the target description) and the osabi, the only remaining
feature that falls back to a compile-time default is the target
byte order (as far as I can see).  Now, the byte order fallback
is only used if the endianness cannot be determined from the
executable file being debugged, so this should be a rare case.
However, it would certainly make sense to allow the target to
provide byte order information in the target description as well.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

RE: GDB for multiple targets

[Marc Khouzam]

 
> From: Ulrich Weigand [mailto:uweigand@de.ibm.com] 
> Sent: Tuesday, December 09, 2008 1:11 PM
>
> Except for the target architecture (which is already provided as
> part of the target description) and the osabi, the only remaining
> feature that falls back to a compile-time default is the target
> byte order (as far as I can see).  Now, the byte order fallback
> is only used if the endianness cannot be determined from the
> executable file being debugged, so this should be a rare case.
> However, it would certainly make sense to allow the target to
> provide byte order information in the target description as well.

When using the 'attach' command to debug a process, GDB is able to 
find the executable automatically.  So, I don't actually use the 'file'
command in those cases.  Would GDB still be able to determine the
endianness in those cases?

thanks
Marc

Re: GDB for multiple targets

[Ulrich Weigand]

Marc Khouzam wrote:
> > From: Ulrich Weigand [mailto:uweigand@de.ibm.com]=20
> > Sent: Tuesday, December 09, 2008 1:11 PM
> >
> > Except for the target architecture (which is already provided as
> > part of the target description) and the osabi, the only remaining
> > feature that falls back to a compile-time default is the target
> > byte order (as far as I can see).  Now, the byte order fallback
> > is only used if the endianness cannot be determined from the
> > executable file being debugged, so this should be a rare case.
> > However, it would certainly make sense to allow the target to
> > provide byte order information in the target description as well.
> 
> When using the 'attach' command to debug a process, GDB is able to=20
> find the executable automatically.  So, I don't actually use the 'file'
> command in those cases.  Would GDB still be able to determine the
> endianness in those cases?

Yes, it would.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com