gdb remote stub for proprietary operating system?

gdb remote stub for proprietary operating system?

[Dominique Toupin (QA/EMC)]

Hi,

I would like to have info on how to implement a gdb remote stub for a
proprietary operating system.
How long does it typically take.

My team will probably do a Linux GDB/MI implementation in DSF
(http://www.eclipse.org/dsdp/dd/).
 
Thanks,

Dominique Toupin

Re: gdb remote stub for proprietary operating system?

[Daniel Jacobowitz]

On Tue, Jan 23, 2007 at 04:16:49PM -0500, Dominique Toupin (QA/EMC) wrote:
> Hi,
> 
> I would like to have info on how to implement a gdb remote stub for a
> proprietary operating system.
> How long does it typically take.

That depends on too many things for us to guess.  For instance, how
your debug interfaces work within your OS, whether you are interested
in threading, and how much OS functionality you want to make available. 
I recommend reading the remote protocol documentation from the GDB
manual, to get a feeling for how much you need.  You won't need all
the packets documented there, though.

> My team will probably do a Linux GDB/MI implementation in DSF
> (http://www.eclipse.org/dsdp/dd/).

Great to hear someone is working on this - I am very interested in
DSF.

-- 
Daniel Jacobowitz
CodeSourcery

RE: gdb remote stub for proprietary operating system?

[Dominique Toupin (QA/EMC)]

Hi,

I have this info
http://sourceware.org/gdb/current/onlinedocs/gdb_18.html#SEC165, when
they say we can ignore the details I was hopping we could ignore the
communication protocol.
Do we have documentation other than sparc-stub.c?

If you have to choose between 3 months, 6 months, 1 year, 2 years, what
would be the guess for how long it would take 1 person to implement the
remote stub to support all the GDB/MI commands?

Thanks for your help,

/Dominique


-----Original Message-----
From: Daniel Jacobowitz [mailto:drow@false.org] 
Sent: January 23, 2007 4:46 PM
To: Dominique Toupin (QA/EMC)
Cc: gdb@sourceware.org
Subject: Re: gdb remote stub for proprietary operating system?

On Tue, Jan 23, 2007 at 04:16:49PM -0500, Dominique Toupin (QA/EMC)
wrote:
> Hi,
> 
> I would like to have info on how to implement a gdb remote stub for a 
> proprietary operating system.
> How long does it typically take.

That depends on too many things for us to guess.  For instance, how your
debug interfaces work within your OS, whether you are interested in
threading, and how much OS functionality you want to make available. 
I recommend reading the remote protocol documentation from the GDB
manual, to get a feeling for how much you need.  You won't need all the
packets documented there, though.

> My team will probably do a Linux GDB/MI implementation in DSF 
> (http://www.eclipse.org/dsdp/dd/).

Great to hear someone is working on this - I am very interested in DSF.

--
Daniel Jacobowitz
CodeSourcery

Re: gdb remote stub for proprietary operating system?

[Daniel Jacobowitz]

On Tue, Jan 23, 2007 at 05:45:36PM -0500, Dominique Toupin (QA/EMC) wrote:
> Hi,
> 
> I have this info
> http://sourceware.org/gdb/current/onlinedocs/gdb_18.html#SEC165, when
> they say we can ignore the details I was hopping we could ignore the
> communication protocol.
> Do we have documentation other than sparc-stub.c?

That is not a good place to look for an OS stub.  Look at the appendix
which documents the communication protocol - I think it's Appendix D. 
You will almost certainly need to write your own implementation of
that, connected to your proprietary debug interface.  And it will give
you a good idea of what is expected of a remote stub.

If you have threads, you'll probably want vCont.  You'll need at least
g/G and m/M (or X).  If you have code in non-writeable or shared
memory, you'll need the z/Z packets.  And so forth.

> If you have to choose between 3 months, 6 months, 1 year, 2 years, what
> would be the guess for how long it would take 1 person to implement the
> remote stub to support all the GDB/MI commands?

It depends on the questions I asked, and the experience of the people
working on the project.  It is probably more like a six month project
than like a one year project.

Of course, if you need a better estimate than that, there are a number
of companies who can do this sort of project :-)

-- 
Daniel Jacobowitz
CodeSourcery