Extended a new target from target remote

Extended a new target from target remote

[Joshua D. Boyd]

I'm trying to work on extensions to  GDB for a remote cluster.  To do
this I am creating an intermediate GDB server to talk to the compute
hardware. 

Using the normal old GDB remote serial protocol works perfectly, but I'm
having trouble figuring out what to do on startup.  When the user in GDB
types "target remote server:2345", after the connection is established
it would be handy to be able to send more information (such as the list
of nodes that the job is spread over) that had be set using set commands
before GDB starts trying to set "Hc-1" or reading the general registers.
Is there any hook to do this, without modifying remote.c?  What I don't
want to have to do is create a new "target cluster" which would end up
mostly duplicating the code in remote.c. 

Thank you.

Re: Extended a new target from target remote

[Daniel Jacobowitz]

On Mon, Oct 26, 2009 at 07:42:02PM -0400, Joshua D. Boyd wrote:
> Using the normal old GDB remote serial protocol works perfectly, but I'm
> having trouble figuring out what to do on startup.  When the user in GDB
> types "target remote server:2345", after the connection is established
> it would be handy to be able to send more information (such as the list
> of nodes that the job is spread over) that had be set using set commands
> before GDB starts trying to set "Hc-1" or reading the general registers.
> Is there any hook to do this, without modifying remote.c?  What I don't
> want to have to do is create a new "target cluster" which would end up
> mostly duplicating the code in remote.c. 

Can you use target extended-remote instead of target remote?  That
supports some process-level extensions - including connecting to a
"not running" target.  Then you can use GDB's normal attach or run
command once you've set up whatever else you need.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Extended a new target from target remote

[Joshua D. Boyd]

On Mon, Oct 26, 2009 at 07:45:05PM -0400, Daniel Jacobowitz wrote:
> On Mon, Oct 26, 2009 at 07:42:02PM -0400, Joshua D. Boyd wrote:
> > Using the normal old GDB remote serial protocol works perfectly, but I'm
> > having trouble figuring out what to do on startup.  When the user in GDB
> > types "target remote server:2345", after the connection is established
> > it would be handy to be able to send more information (such as the list
> > of nodes that the job is spread over) that had be set using set commands
> > before GDB starts trying to set "Hc-1" or reading the general registers.
> > Is there any hook to do this, without modifying remote.c?  What I don't
> > want to have to do is create a new "target cluster" which would end up
> > mostly duplicating the code in remote.c. 
> 
> Can you use target extended-remote instead of target remote?  That
> supports some process-level extensions - including connecting to a
> "not running" target.  Then you can use GDB's normal attach or run
> command once you've set up whatever else you need.

What version of GDB was that added in?  I should have mentioned that I
picked up hacking on the internal GDB 6.1, which I realize is extremely
old and I should have mentioned that up front, and is a little
embarassing.  

Re: Extended a new target from target remote

[Daniel Jacobowitz]

On Mon, Oct 26, 2009 at 08:11:48PM -0400, Joshua D. Boyd wrote:
> What version of GDB was that added in?  I should have mentioned that I
> picked up hacking on the internal GDB 6.1, which I realize is extremely
> old and I should have mentioned that up front, and is a little
> embarassing.  

That version probably *has* extended-remote, but don't use it.  If you
are interested in anything remotely current, update to GDB 7.0 just
released.

So you are making changes to GDB, just not to the remote target?

-- 
Daniel Jacobowitz
CodeSourcery

Re: Extended a new target from target remote

[Joshua D. Boyd]

On Mon, Oct 26, 2009 at 10:21:55PM -0400, Daniel Jacobowitz wrote:
> On Mon, Oct 26, 2009 at 08:11:48PM -0400, Joshua D. Boyd wrote:
> > What version of GDB was that added in?  I should have mentioned that I
> > picked up hacking on the internal GDB 6.1, which I realize is extremely
> > old and I should have mentioned that up front, and is a little
> > embarassing.  
> 
> That version probably *has* extended-remote, but don't use it.  If you
> are interested in anything remotely current, update to GDB 7.0 just
> released.

It does have extended-remote, but I will refrain from using it.

I tried briefly to move this work up to GDB 7.0, but I got trying to
move the bfd changes forward and had to put the upgrade to the side for
now.  GDB 7.0 certainly looks great though.  This is the first time I've
ran around installing a new version of GDB from source on every linux
machine I use.
 
> So you are making changes to GDB, just not to the remote target?

I'm not certain if you mean a remote target in terms of something new
compared to "target remote" or "target core", or if you mean a remote
target as in what is being debugged on the cluster. 

I have added a new target (-tdep.[ch] + configuration/build changes), a
few new commands, a GDB server in the middle to hide from the GDB client
the fact that multiple connections are involved  and as well as protocol
differences (this does not use TCP), and a GDB "server" embedded in the
compute kernel (the system uses a lightweight compute kernel instead of 
linux.). 

I am new to working on GDB as anything other than a user and am trying
to come up to speed quickly on the parts it looks like I need to
complete a first implementation.

Re: Extended a new target from target remote

[Daniel Jacobowitz]

On Mon, Oct 26, 2009 at 10:39:53PM -0400, Joshua D. Boyd wrote:
> I tried briefly to move this work up to GDB 7.0, but I got trying to
> move the bfd changes forward and had to put the upgrade to the side for
> now.  GDB 7.0 certainly looks great though.  This is the first time I've
> ran around installing a new version of GDB from source on every linux
> machine I use.

OK.  That's a pity.  You would have an easier time with this problem
in the current GDB sources.

-- 
Daniel Jacobowitz
CodeSourcery