How to tell gdb to exit?

How to tell gdb to exit?

[Grant Edwards]

I'm trying to figure out how to run gdb from a shell script,
and everything works, except I can't get gdb to exit.  What I
want to do is:

 1) set target to /dev/ttyS0
 2) load an elf file
 3) start it (continue)
 4) exit gdb

Steps 1-3 work great, but at step 4) gdb won't accept a new
command in human-interface mode, so this doesn't work:

  #!/bin/bash
  h8300-elf-gdb <<EOF
  set arch h8300h
  target remote /dev/ttyS0
  load test.elf
  cont
  quit
  EOF

I tried "detach" instead of "cont" since the info file says
that it continues exection, but it doesn't actual seem to do
that for remote targets.

  
In MI mode, I can't figure out what the "quit" command is, and
it just hangs on EOF -- so this doesn't work either:

  #!/bin/bash
  h8300-elf-gdb -interpreter=mi <<EOF
  10-target-select async /dev/ttyS0
  20-target-download test.elf
  30-exec-continue
  EOF

I'm sure I'm missing an obvious clue, could somebody point it
out to me?
  
-- 
Grant Edwards
grante@visi.com

Re: How to tell gdb to exit?

[Grant Edwards]

On Thu, May 06, 2004 at 10:50:14AM -0500, Grant Edwards wrote:

> In MI mode, I can't figure out what the "quit" command is, and
> it just hangs on EOF -- so this doesn't work either:
> 
>   #!/bin/bash
>   h8300-elf-gdb -interpreter=mi <<EOF
>   10-target-select async /dev/ttyS0
>   20-target-download test.elf
>   30-exec-continue
>   EOF

I've also tried -gdb-exit.  Gdb refuses to exit since it's
obviously smarter than I and knows a-priori that I don't know
what I'm talking about and I obviously don't _really_ want it
to exit.

-target-detch and -target-disconnect don't make any difference
either.

-- 
Grant Edwards
grante@visi.com

Re: How to tell gdb to exit?

[Grant Edwards]

On Thu, May 06, 2004 at 11:09:44AM -0500, Grant Edwards wrote:

> -target-detch and -target-disconnect don't make any difference
> either.

My bad.  It looks like -target-disconnect works afer all.  [of
course I swear I tried it before and it didn't.] -gdb-exit
still refuses to exit, but it will exit on EOF.

So, this seems to work:

  #!/bin/bash
  h8300-elf-gdb -interpreter=mi <<EOF
  10-target-select async /dev/ttyS0
  20-target-download test.elf
  30-exec-continue
  40-target-disconnect
  EOF

I messed around with this on and off for days, and couldn't
find the answer, but as soon as I put my foot in my mouth
publically, the answer appears.  Odd, that.
  
--   
Grant Edwards
grante@visi.com

Re: How to tell gdb to exit?

[Daniel Jacobowitz]

On Thu, May 06, 2004 at 11:16:46AM -0500, Grant Edwards wrote:
> On Thu, May 06, 2004 at 11:09:44AM -0500, Grant Edwards wrote:
> 
> > -target-detch and -target-disconnect don't make any difference
> > either.
> 
> My bad.  It looks like -target-disconnect works afer all.  [of
> course I swear I tried it before and it didn't.] -gdb-exit
> still refuses to exit, but it will exit on EOF.
> 
> So, this seems to work:
> 
>   #!/bin/bash
>   h8300-elf-gdb -interpreter=mi <<EOF
>   10-target-select async /dev/ttyS0
>   20-target-download test.elf
>   30-exec-continue
>   40-target-disconnect
>   EOF
> 
> I messed around with this on and off for days, and couldn't
> find the answer, but as soon as I put my foot in my mouth
> publically, the answer appears.  Odd, that.

This will leave your target stopped, presumably.  The "disconnect"
commandd for the CLI will do the same thing.  Is that what you want?

-- 
Daniel Jacobowitz

Re: How to tell gdb to exit?

[Grant Edwards]

On Thu, May 06, 2004 at 12:18:58PM -0400, Daniel Jacobowitz wrote:

> > My bad.  It looks like -target-disconnect works afer all.  [of
> > course I swear I tried it before and it didn't.] -gdb-exit
> > still refuses to exit, but it will exit on EOF.
> > 
> > So, this seems to work:
> > 
> >   #!/bin/bash
> >   h8300-elf-gdb -interpreter=mi <<EOF
> >   10-target-select async /dev/ttyS0
> >   20-target-download test.elf
> >   30-exec-continue
> >   40-target-disconnect
> >   EOF
> > 
> > I messed around with this on and off for days, and couldn't
> > find the answer, but as soon as I put my foot in my mouth
> > publically, the answer appears.  Odd, that.
> 
> This will leave your target stopped, presumably.

Perhaps it tries to stop the target, but it can't. Once the
program starts, the gdb stub is "gone".  My app has taken over
the UART for use as console I/O, and it's no longer possible to
communicate with the gdb stub[1].  It would be nice to have
another UART so one could be used for console I/O and the other
for GDB, but such is life.

> The "disconnect" commandd for the CLI will do the same thing.
> Is that what you want?

With the CLI, you can only send the disconnect command after
you've stopped the target.  In my script above, I'm sending the
disconnect command while the target is still running. I guess
since it's no longer possible to stop the applicaion from gdb,
it keeps running.

Does that mean there's actually no way to tell gdb to "just
exit"?  By "just exit" I mean don't try to muck with the
target: Just call exit().

[1] I do have gdb-mangling that I can enable in my console
    output routine so that I can have console output while
    continuing to use gdb+gdb-stub. But, there's no way to
    handle console input via gdb, so if I want to use console
    input, I have to cut gdb out of the loop rather
    unceremoniously.

-- 
Grant Edwards
grante@visi.com

Re: How to tell gdb to exit?

[Daniel Jacobowitz]

On Thu, May 06, 2004 at 11:35:21AM -0500, Grant Edwards wrote:
> On Thu, May 06, 2004 at 12:18:58PM -0400, Daniel Jacobowitz wrote:
> 
> > > My bad.  It looks like -target-disconnect works afer all.  [of
> > > course I swear I tried it before and it didn't.] -gdb-exit
> > > still refuses to exit, but it will exit on EOF.
> > > 
> > > So, this seems to work:
> > > 
> > >   #!/bin/bash
> > >   h8300-elf-gdb -interpreter=mi <<EOF
> > >   10-target-select async /dev/ttyS0
> > >   20-target-download test.elf
> > >   30-exec-continue
> > >   40-target-disconnect
> > >   EOF
> > > 
> > > I messed around with this on and off for days, and couldn't
> > > find the answer, but as soon as I put my foot in my mouth
> > > publically, the answer appears.  Odd, that.
> > 
> > This will leave your target stopped, presumably.
> 
> Perhaps it tries to stop the target, but it can't. Once the
> program starts, the gdb stub is "gone".  My app has taken over
> the UART for use as console I/O, and it's no longer possible to
> communicate with the gdb stub[1].  It would be nice to have
> another UART so one could be used for console I/O and the other
> for GDB, but such is life.
> 
> > The "disconnect" commandd for the CLI will do the same thing.
> > Is that what you want?
> 
> With the CLI, you can only send the disconnect command after
> you've stopped the target.  In my script above, I'm sending the
> disconnect command while the target is still running. I guess
> since it's no longer possible to stop the applicaion from gdb,
> it keeps running.

Try target async-remote?  I hadn't realized you were using async in the
MI mode; in that case, disconnect will just break the connection.

-- 
Daniel Jacobowitz

Re: How to tell gdb to exit?

[Ian Lance Taylor]

Grant Edwards <grante@visi.com> writes:

> I messed around with this on and off for days, and couldn't
> find the answer, but as soon as I put my foot in my mouth
> publically, the answer appears.  Odd, that.

I actually find that this is a fairly effective technique for solving
a problem.  Send out a message, and then the answer occurs to you.
The more people to whom you send the message, the more likely you are
to find the answer yourself.

I've learned to exploit this fact by composing the message but
delaying the actual sending for a period of time.  Sometimes the
answer will come to me before the message actually goes out.

You may think I'm kidding, but I'm not.  At least not wholly.

Ian

Re: How to tell gdb to exit?

[Grant Edwards]

>> I messed around with this on and off for days, and couldn't
>> find the answer, but as soon as I put my foot in my mouth
>> publically, the answer appears.  Odd, that.
> 
> I actually find that this is a fairly effective technique for solving
> a problem.  Send out a message, and then the answer occurs to you.
> The more people to whom you send the message, the more likely you are
> to find the answer yourself.

One might think that the answer should occur while one is
composing the message -- trying to explain the problem in
sufficient detail for others to understand often sometimes
reveals a solution.  While this does happen, it also seems that
at least as often the answer appears about 20 minutes later.

> I've learned to exploit this fact by composing the message but
> delaying the actual sending for a period of time.  Sometimes the
> answer will come to me before the message actually goes out.

I should try that...

-- 
Grant Edwards
grante@visi.com

Re: How to tell gdb to exit?

[Daniel Jacobowitz]

On Thu, May 06, 2004 at 10:50:14AM -0500, Grant Edwards wrote:
> 
> I'm trying to figure out how to run gdb from a shell script,
> and everything works, except I can't get gdb to exit.  What I
> want to do is:
> 
>  1) set target to /dev/ttyS0
>  2) load an elf file
>  3) start it (continue)
>  4) exit gdb
> 
> Steps 1-3 work great, but at step 4) gdb won't accept a new
> command in human-interface mode, so this doesn't work:
> 
>   #!/bin/bash
>   h8300-elf-gdb <<EOF
>   set arch h8300h
>   target remote /dev/ttyS0
>   load test.elf
>   cont
>   quit
>   EOF
> 
> I tried "detach" instead of "cont" since the info file says
> that it continues exection, but it doesn't actual seem to do
> that for remote targets.

It should.  Whether it does or not depends on your remote stub, though.

-- 
Daniel Jacobowitz

Re: How to tell gdb to exit?

[Grant Edwards]

On Thu, May 06, 2004 at 12:10:34PM -0400, Daniel Jacobowitz wrote:

> > I tried "detach" instead of "cont" since the info file says
> > that it continues exection, but it doesn't actual seem to do
> > that for remote targets.
> 
> It should.  Whether it does or not depends on your remote stub, though.

Probably my stub's fault.

-- 
Grant Edwards
grante@visi.com