public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* gdb problem
@ 2000-06-02  5:50 Tom M. Yeh
  0 siblings, 0 replies; 35+ messages in thread
From: Tom M. Yeh @ 2000-06-02  5:50 UTC (permalink / raw)
  To: Cygwin

I installed the latest version of Cygwin (5/15/00). When I used gdb to debug
a program, gdb popped up a dialog saying it cannot open the source file.
What happens? The problem is still there even I compiled a program as simple
as "hello world".

Regards,
Tom

Here is the stack trace.
----------------------------------------------
couldn't stat "/home/tomyeh/myprj/nolib/main.c": no such file or directory
    while executing
"file mtime $f"
    (object "::.srcwin0.srcwin.container.pane1.childsite.con" method
"::SrcTextWin::_mtime_changed" body line 7)
    invoked from within
"_mtime_changed $filename"
    (object "::.srcwin0.srcwin.container.pane1.childsite.con" method
"::SrcTextWin::FillSource" body line 10)
    invoked from within
"FillSource t $tagname $filename $funcname $line $addr $pc_addr $lib"
    ("SOURCE" arm line 2)
    invoked from within
"switch $current(mode) {
    SOURCE {
      FillSource t $tagname $filename $funcname $line $addr $pc_addr $lib
    }
    ASSEMBLY {
      FillAssembly..."
    (object "::.srcwin0.srcwin.container.pane1.childsite.con" method
"::SrcTextWin::location" body line 26)
    invoked from within
"$twin location $tag $name $funcname $line $addr $pc_addr $lib"
    (object "::.srcwin0.srcwin" method "::SrcWin::location" body line 52)
    invoked from within
"location BROWSE_TAG [list $val "" $full 0 0 0 {}]"
    (object "::.srcwin0.srcwin" method "::SrcWin::_name" body line 22)
    invoked from within
"::.srcwin0.srcwin _name .srcwin0.srcwin.container.pane3.childsite.con.name
main.c"
    (in namespace inscope "::SrcWin" script line 1)
    invoked from within
"namespace inscope ::SrcWin {::.srcwin0.srcwin _name}
.srcwin0.srcwin.container.pane3.childsite.con.name main.c"
    ("after" script)errorCode is POSIX ENOENT {no such file or directory}


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: gdb problem
  2012-05-04 19:20         ` Ken Brown
@ 2012-05-05  1:58           ` Ryan Johnson
  0 siblings, 0 replies; 35+ messages in thread
From: Ryan Johnson @ 2012-05-05  1:58 UTC (permalink / raw)
  To: cygwin

On 04/05/2012 1:19 PM, Ken Brown wrote:
> On 5/3/2012 11:10 PM, Christopher Faylor wrote:
>> On Thu, May 03, 2012 at 04:05:04PM -0400, Ken Brown wrote:
>>> On 10/23/2011 5:47 PM, Ken Brown wrote:
>>>> On 10/23/2011 3:04 PM, Christopher Faylor wrote:
>>>>> On Sat, Oct 22, 2011 at 04:37:55PM -0400, Ken Brown wrote:
>>>>>> The attached testcase illustrates a problem with `gdb -i=mi'. I've
>>>>>> tested both gdb 7.3.50-1 and 7.3.50-2, with cygwin 1.7.9 as well 
>>>>>> as with
>>>>>> several recent snapshots (including 2011-10-22).
>>>>>>
>>>>>> Under some circumstances, if gdb -i=mi is started and given several
>>>>>> input lines at once, it only prints part of the output before 
>>>>>> stopping.
>>>>>> I've been able to reproduce this once in a while while working
>>>>>> interactively (by copying and pasting the whole bunch of input 
>>>>>> lines);
>>>>>> in this case one can press Return to get the rest of the output. But
>>>>>> the problem happens consistently with the attached test case, 
>>>>>> which runs
>>>>>> gdb in a subprocess. One has to kill the gdb process before the main
>>>>>> program exits.
>>>>>>
>>>>>> The STC runs as expected on Linux.
>>>>>
>>>>> Thanks for the STC. I had to tweak it to actually see how it was 
>>>>> supposed
>>>>> to work on Linux since only a limited number of lines from the pty 
>>>>> were
>>>>> being output. I've included the revised test case below.
>>>>>
>>>>> I made a simple change to Cygwin which will probably cause subtle
>>>>> problems somewhere down the line. At least for now it seems to 
>>>>> make gdb
>>>>> operate as expected.
>>>>>
>>>>> I'm building a new snapshot now.
>>>>
>>>> Thanks, that fixes it (as well as the emacs problem that originally 
>>>> led
>>>> to this report). In case there are emacs users wondering what this is
>>>> about, I've been testing emacs-24, which uses gdb -i=mi instead of the
>>>> obsolete gdb --annotate=3 used by emacs-23.
>>>
>>> I'm replying to this old thread because the problem is back again in
>>> cygwin-1.7.14-2.  I haven't checked to see exactly when it first
>>> reappeared (but I'll do this if it would help.)  The same STC as before
>>> exhibits the problem; I'm attaching it for convenience.
>>
>> Thanks for the heads up.  This should be fixed in the next snapshot.
>
> Confirmed.  Thanks.
>
> Ryan, if you're reading this, the problems you were seeing with M-x 
> gdb in emacs should be fixed now.
Sorry, do you mean the problems with emacs-23 -annotate=3 or emacs-24 -mi?

Ryan


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: gdb problem
  2012-05-04  3:10       ` Christopher Faylor
@ 2012-05-04 19:20         ` Ken Brown
  2012-05-05  1:58           ` Ryan Johnson
  0 siblings, 1 reply; 35+ messages in thread
From: Ken Brown @ 2012-05-04 19:20 UTC (permalink / raw)
  To: cygwin

On 5/3/2012 11:10 PM, Christopher Faylor wrote:
> On Thu, May 03, 2012 at 04:05:04PM -0400, Ken Brown wrote:
>> On 10/23/2011 5:47 PM, Ken Brown wrote:
>>> On 10/23/2011 3:04 PM, Christopher Faylor wrote:
>>>> On Sat, Oct 22, 2011 at 04:37:55PM -0400, Ken Brown wrote:
>>>>> The attached testcase illustrates a problem with `gdb -i=mi'. I've
>>>>> tested both gdb 7.3.50-1 and 7.3.50-2, with cygwin 1.7.9 as well as with
>>>>> several recent snapshots (including 2011-10-22).
>>>>>
>>>>> Under some circumstances, if gdb -i=mi is started and given several
>>>>> input lines at once, it only prints part of the output before stopping.
>>>>> I've been able to reproduce this once in a while while working
>>>>> interactively (by copying and pasting the whole bunch of input lines);
>>>>> in this case one can press Return to get the rest of the output. But
>>>>> the problem happens consistently with the attached test case, which runs
>>>>> gdb in a subprocess. One has to kill the gdb process before the main
>>>>> program exits.
>>>>>
>>>>> The STC runs as expected on Linux.
>>>>
>>>> Thanks for the STC. I had to tweak it to actually see how it was supposed
>>>> to work on Linux since only a limited number of lines from the pty were
>>>> being output. I've included the revised test case below.
>>>>
>>>> I made a simple change to Cygwin which will probably cause subtle
>>>> problems somewhere down the line. At least for now it seems to make gdb
>>>> operate as expected.
>>>>
>>>> I'm building a new snapshot now.
>>>
>>> Thanks, that fixes it (as well as the emacs problem that originally led
>>> to this report). In case there are emacs users wondering what this is
>>> about, I've been testing emacs-24, which uses gdb -i=mi instead of the
>>> obsolete gdb --annotate=3 used by emacs-23.
>>
>> I'm replying to this old thread because the problem is back again in
>> cygwin-1.7.14-2.  I haven't checked to see exactly when it first
>> reappeared (but I'll do this if it would help.)  The same STC as before
>> exhibits the problem; I'm attaching it for convenience.
>
> Thanks for the heads up.  This should be fixed in the next snapshot.

Confirmed.  Thanks.

Ryan, if you're reading this, the problems you were seeing with M-x gdb 
in emacs should be fixed now.

> Incidentally, I've started putting longer explications of what I've
> debugged and how I debugged it in a "DevNotes" file in the source:
>
> http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/DevNotes?cvsroot=src
>
> I hope to keep this up-to-date with extended rationales for why things
> were done a certain way and with descriptions about the steps that I
> used to track down a problem.
>
> This file is not a substitute for comments (we've been trying to be more
> diligent about commenting changes in the source) or a ChangeLog but I
> hope that it will help me in the future when I have to figure out "Why
> the heck did I make that change?"

Great idea.  It's also useful for people like me who like to understand 
what caused a problem they reported and how it got fixed.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: gdb problem
  2012-05-03 20:05     ` Ken Brown
@ 2012-05-04  3:10       ` Christopher Faylor
  2012-05-04 19:20         ` Ken Brown
  0 siblings, 1 reply; 35+ messages in thread
From: Christopher Faylor @ 2012-05-04  3:10 UTC (permalink / raw)
  To: cygwin

On Thu, May 03, 2012 at 04:05:04PM -0400, Ken Brown wrote:
>On 10/23/2011 5:47 PM, Ken Brown wrote:
>> On 10/23/2011 3:04 PM, Christopher Faylor wrote:
>>> On Sat, Oct 22, 2011 at 04:37:55PM -0400, Ken Brown wrote:
>>>> The attached testcase illustrates a problem with `gdb -i=mi'. I've
>>>> tested both gdb 7.3.50-1 and 7.3.50-2, with cygwin 1.7.9 as well as with
>>>> several recent snapshots (including 2011-10-22).
>>>>
>>>> Under some circumstances, if gdb -i=mi is started and given several
>>>> input lines at once, it only prints part of the output before stopping.
>>>> I've been able to reproduce this once in a while while working
>>>> interactively (by copying and pasting the whole bunch of input lines);
>>>> in this case one can press Return to get the rest of the output. But
>>>> the problem happens consistently with the attached test case, which runs
>>>> gdb in a subprocess. One has to kill the gdb process before the main
>>>> program exits.
>>>>
>>>> The STC runs as expected on Linux.
>>>
>>> Thanks for the STC. I had to tweak it to actually see how it was supposed
>>> to work on Linux since only a limited number of lines from the pty were
>>> being output. I've included the revised test case below.
>>>
>>> I made a simple change to Cygwin which will probably cause subtle
>>> problems somewhere down the line. At least for now it seems to make gdb
>>> operate as expected.
>>>
>>> I'm building a new snapshot now.
>>
>> Thanks, that fixes it (as well as the emacs problem that originally led
>> to this report). In case there are emacs users wondering what this is
>> about, I've been testing emacs-24, which uses gdb -i=mi instead of the
>> obsolete gdb --annotate=3 used by emacs-23.
>
>I'm replying to this old thread because the problem is back again in 
>cygwin-1.7.14-2.  I haven't checked to see exactly when it first 
>reappeared (but I'll do this if it would help.)  The same STC as before 
>exhibits the problem; I'm attaching it for convenience.

Thanks for the heads up.  This should be fixed in the next snapshot.

Incidentally, I've started putting longer explications of what I've
debugged and how I debugged it in a "DevNotes" file in the source:

http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/DevNotes?cvsroot=src

I hope to keep this up-to-date with extended rationales for why things
were done a certain way and with descriptions about the steps that I
used to track down a problem.

This file is not a substitute for comments (we've been trying to be more
diligent about commenting changes in the source) or a ChangeLog but I
hope that it will help me in the future when I have to figure out "Why
the heck did I make that change?"

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: gdb problem
  2011-10-23 21:48   ` Ken Brown
@ 2012-05-03 20:05     ` Ken Brown
  2012-05-04  3:10       ` Christopher Faylor
  0 siblings, 1 reply; 35+ messages in thread
From: Ken Brown @ 2012-05-03 20:05 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 1897 bytes --]

On 10/23/2011 5:47 PM, Ken Brown wrote:
> On 10/23/2011 3:04 PM, Christopher Faylor wrote:
>> On Sat, Oct 22, 2011 at 04:37:55PM -0400, Ken Brown wrote:
>>> The attached testcase illustrates a problem with `gdb -i=mi'. I've
>>> tested both gdb 7.3.50-1 and 7.3.50-2, with cygwin 1.7.9 as well as with
>>> several recent snapshots (including 2011-10-22).
>>>
>>> Under some circumstances, if gdb -i=mi is started and given several
>>> input lines at once, it only prints part of the output before stopping.
>>> I've been able to reproduce this once in a while while working
>>> interactively (by copying and pasting the whole bunch of input lines);
>>> in this case one can press Return to get the rest of the output. But
>>> the problem happens consistently with the attached test case, which runs
>>> gdb in a subprocess. One has to kill the gdb process before the main
>>> program exits.
>>>
>>> The STC runs as expected on Linux.
>>
>> Thanks for the STC. I had to tweak it to actually see how it was supposed
>> to work on Linux since only a limited number of lines from the pty were
>> being output. I've included the revised test case below.
>>
>> I made a simple change to Cygwin which will probably cause subtle
>> problems somewhere down the line. At least for now it seems to make gdb
>> operate as expected.
>>
>> I'm building a new snapshot now.
>
> Thanks, that fixes it (as well as the emacs problem that originally led
> to this report). In case there are emacs users wondering what this is
> about, I've been testing emacs-24, which uses gdb -i=mi instead of the
> obsolete gdb --annotate=3 used by emacs-23.

I'm replying to this old thread because the problem is back again in 
cygwin-1.7.14-2.  I haven't checked to see exactly when it first 
reappeared (but I'll do this if it would help.)  The same STC as before 
exhibits the problem; I'm attaching it for convenience.

Ken


[-- Attachment #2: gdbstc.cc --]
[-- Type: text/plain, Size: 1715 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <pty.h>
#include <string.h>
#include <sys/wait.h>

void get_output (int fd);

int
main (int argc, const char **argv) 
{
  int master;
  pid_t pid;

  if ((pid = forkpty (&master, NULL, NULL, NULL)) < 0)
    {
      perror ("forkpty");
      exit (1);
    }
  /* child */
  if (pid == 0) 
    {
      const char *av[100];
      // putenv ("HOME=/tmp");
      int i = 0;
#ifdef STRACE_GDB
      av[i++] = "strace";
      av[i++] = "-o";
      av[i++] = "/tmp/strace.out";
#ifdef __CYGWIN__
      av[i++] = "--mask=all+paranoid";
#endif
#endif
      av[i++] = argv[1] ?: "gdb";
      fprintf (stderr, "*** using %s\n", av[0]);
      av[i++] = "-i=mi";
      av[i] = NULL;
      execvp (av[0], (char * const *) av);
      /* shouldn't get here */
      exit (1);
    }
  /* parent */
  const char *input[20];

  int i = 0;
  input[i++] = "1-inferior-tty-set /dev/pty3\n";
  input[i++] = "2-gdb-set height 0\n";
  input[i++] = "3-gdb-set non-stop 1\n";
  input[i++] = "4-file-list-exec-source-files\n";
  input[i++] = "5-file-list-exec-source-file\n";
  input[i++] = "6-gdb-show prompt\n";
  input[i++] = "7-stack-info-frame\n";
  input[i++] = "8-thread-info\n";
  input[i++] = "9-break-list\n";
  input[i++] = "q\n";
  input[i] = NULL;

  for (int i = 0; input[i]; ++i)
    {
      write (master, input[i], strlen (input[i]));
      // sleep (1);
    }
  get_output (master);
  wait (NULL);
}

void
get_output (int fd)
{
  char buf[4096];

  while (1)
    {
      int nread = read (fd, buf, sizeof (buf));
      if (nread > 0)
	write (STDOUT_FILENO, buf, nread);
      else
	{
	  printf ("No more output.  nread %d\n", nread);
	  break;
	}
    }
}




[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: gdb problem
  2011-10-23 19:04 ` Christopher Faylor
@ 2011-10-23 21:48   ` Ken Brown
  2012-05-03 20:05     ` Ken Brown
  0 siblings, 1 reply; 35+ messages in thread
From: Ken Brown @ 2011-10-23 21:48 UTC (permalink / raw)
  To: cygwin

On 10/23/2011 3:04 PM, Christopher Faylor wrote:
> On Sat, Oct 22, 2011 at 04:37:55PM -0400, Ken Brown wrote:
>> The attached testcase illustrates a problem with `gdb -i=mi'.  I've
>> tested both gdb 7.3.50-1 and 7.3.50-2, with cygwin 1.7.9 as well as with
>> several recent snapshots (including 2011-10-22).
>>
>> Under some circumstances, if gdb -i=mi is started and given several
>> input lines at once, it only prints part of the output before stopping.
>>   I've been able to reproduce this once in a while while working
>> interactively (by copying and pasting the whole bunch of input lines);
>> in this case one can press Return to get the rest of the output.  But
>> the problem happens consistently with the attached test case, which runs
>> gdb in a subprocess.  One has to kill the gdb process before the main
>> program exits.
>>
>> The STC runs as expected on Linux.
>
> Thanks for the STC.  I had to tweak it to actually see how it was supposed
> to work on Linux since only a limited number of lines from the pty were
> being output.  I've included the revised test case below.
>
> I made a simple change to Cygwin which will probably cause subtle
> problems somewhere down the line.  At least for now it seems to make gdb
> operate as expected.
>
> I'm building a new snapshot now.

Thanks, that fixes it (as well as the emacs problem that originally led 
to this report).  In case there are emacs users wondering what this is 
about, I've been testing emacs-24, which uses gdb -i=mi instead of the 
obsolete gdb --annotate=3 used by emacs-23.

Ken


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: gdb problem
  2011-10-22 20:38 Ken Brown
  2011-10-23  2:37 ` jan.kolar
@ 2011-10-23 19:04 ` Christopher Faylor
  2011-10-23 21:48   ` Ken Brown
  1 sibling, 1 reply; 35+ messages in thread
From: Christopher Faylor @ 2011-10-23 19:04 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]

On Sat, Oct 22, 2011 at 04:37:55PM -0400, Ken Brown wrote:
>The attached testcase illustrates a problem with `gdb -i=mi'.  I've 
>tested both gdb 7.3.50-1 and 7.3.50-2, with cygwin 1.7.9 as well as with 
>several recent snapshots (including 2011-10-22).
>
>Under some circumstances, if gdb -i=mi is started and given several 
>input lines at once, it only prints part of the output before stopping. 
>  I've been able to reproduce this once in a while while working 
>interactively (by copying and pasting the whole bunch of input lines); 
>in this case one can press Return to get the rest of the output.  But 
>the problem happens consistently with the attached test case, which runs 
>gdb in a subprocess.  One has to kill the gdb process before the main 
>program exits.
>
>The STC runs as expected on Linux.

Thanks for the STC.  I had to tweak it to actually see how it was supposed
to work on Linux since only a limited number of lines from the pty were
being output.  I've included the revised test case below.

I made a simple change to Cygwin which will probably cause subtle
problems somewhere down the line.  At least for now it seems to make gdb
operate as expected.

I'm building a new snapshot now.

cgf

[-- Attachment #2: gdbstc.cc --]
[-- Type: text/x-c, Size: 1714 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <pty.h>
#include <string.h>
#include <sys/wait.h>

void get_output (int fd);

int
main (int argc, const char **argv) 
{
  int master;
  pid_t pid;

  if ((pid = forkpty (&master, NULL, NULL, NULL)) < 0)
    {
      perror ("forkpty");
      exit (1);
    }
  /* child */
  if (pid == 0) 
    {
      const char *av[100];
      // putenv ("HOME=/tmp");
      int i = 0;
#ifdef STRACE_GDB
      av[i++] = "strace";
      av[i++] = "-o";
      av[i++] = "/tmp/strace.out";
#ifdef __CYGWIN__
      av[i++] = "--mask=all+paranoid";
#endif
#endif
      av[i++] = argv[1] ?: "gdb";
      fprintf (stderr, "*** using %s\n", av[0]);
      av[i++] = "-i=mi";
      av[i] = NULL;
      execvp (av[0], (char * const *) av);
      /* shouldn't get here */
      exit (1);
    }
  /* parent */
  const char *input[20];

  int i = 0;
  input[i++] = "1-inferior-tty-set /dev/pty3\n";
  input[i++] = "2-gdb-set height 0\n";
  input[i++] = "3-gdb-set non-stop 1\n";
  input[i++] = "4-file-list-exec-source-files\n";
  input[i++] = "5-file-list-exec-source-file\n";
  input[i++] = "6-gdb-show prompt\n";
  input[i++] = "7-stack-info-frame\n";
  input[i++] = "8-thread-info\n";
  input[i++] = "9-break-list\n";
  input[i++] = "q\n";
  input[i] = NULL;

  for (int i = 0; input[i]; ++i)
    {
      write (master, input[i], strlen (input[i]));
      // sleep (1);
    }
  get_output (master);
  wait (NULL);
}

void
get_output (int fd)
{
  char buf[4096];

  while (1)
    {
      int nread = read (fd, buf, sizeof (buf));
      if (nread > 0)
	write (STDOUT_FILENO, buf, nread);
      else
	{
	  printf ("No more output.  nread %d\n", nread);
	  break;
	}
    }
}



[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: gdb problem
  2011-10-22 20:38 Ken Brown
@ 2011-10-23  2:37 ` jan.kolar
  2011-10-23 19:04 ` Christopher Faylor
  1 sibling, 0 replies; 35+ messages in thread
From: jan.kolar @ 2011-10-23  2:37 UTC (permalink / raw)
  To: cygwin



Difference with Linux might be matter of timing. (Or, might gdb version).

The problem is that gdb calls poll() while it has (all) data already in libc
buffers.
It also calls fileno() and isatty() arround that time.
(Also {m,c,re}alloc, free, pthread_sigmask, vsprints)

Gdb first calls poll() with timeout=0 and if there are no data on fd=0, 
it calls again poll() with timeout=-1. 
I verified the both calls come directly from gdb.exe, from the same address
(0x00456a8f when gdb is at 00400000-00892000 - gdb 7.3.50-1)

Is there in gdb's source visible, that a bad combination of fgetc (on
buffered stream)
and poll (on fd - unbuffered) ? 

JK

--
This was usefull:
break fgetc
break __srget_r         (  __sread        __srget_r     _read_r     read )
watch ((FILE *) 0x6116f370) -> _p
#  where the addres is    p fp         from  __srget_r()
break *(_sigbe+69)
break *(_sigfe+75)
break poll
break cygwin_select


-- 
View this message in context: http://old.nabble.com/gdb-problem-tp32702884p32703871.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 35+ messages in thread

* gdb problem
@ 2011-10-22 20:38 Ken Brown
  2011-10-23  2:37 ` jan.kolar
  2011-10-23 19:04 ` Christopher Faylor
  0 siblings, 2 replies; 35+ messages in thread
From: Ken Brown @ 2011-10-22 20:38 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 942 bytes --]

The attached testcase illustrates a problem with `gdb -i=mi'.  I've 
tested both gdb 7.3.50-1 and 7.3.50-2, with cygwin 1.7.9 as well as with 
several recent snapshots (including 2011-10-22).

Under some circumstances, if gdb -i=mi is started and given several 
input lines at once, it only prints part of the output before stopping. 
  I've been able to reproduce this once in a while while working 
interactively (by copying and pasting the whole bunch of input lines); 
in this case one can press Return to get the rest of the output.  But 
the problem happens consistently with the attached test case, which runs 
gdb in a subprocess.  One has to kill the gdb process before the main 
program exits.

The STC runs as expected on Linux.

The particular input lines I gave gdb are precisely those that emacs 
sends in the problem I reported in

   http://cygwin.com/ml/cygwin/2011-10/msg00357.html .

I don't know if this is relevant.

Ken

[-- Attachment #2: stc.c --]
[-- Type: text/plain, Size: 1340 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <pty.h>
#include <string.h>
#include <sys/wait.h>

void get_output (int fd);

int
main () 
{
  int master;
  pid_t pid;

  if ((pid = forkpty (&master, NULL, NULL, NULL)) < 0)
    {
      perror ("forkpty");
      exit (1);
    }
  /* child */
  if (pid == 0) 
    {
      char  *argv[3];
      argv[0] = "gdb";
      argv[1] = "-i=mi";
      argv[2] = '\0';
      execvp (argv[0], argv);
      /* shouldn't get here */
      exit (1);
    }
  /* parent */
  char *input[10];

  input[0] = "1-inferior-tty-set /dev/pty3\n";
  input[1] = "2-gdb-set height 0\n";
  input[2] = "3-gdb-set non-stop 1\n";
  input[3] = "4-file-list-exec-source-files\n";
  input[4] = "5-file-list-exec-source-file\n";
  input[5] = "6-gdb-show prompt\n";
  input[6] = "7-stack-info-frame\n";
  input[7] = "8-thread-info\n";
  input[8] = "9-break-list\n";
  input[9] = "q\n";

  int i;
  for (i = 0; i < 10; ++i)
    write (master, input[i], strlen (input[i]));
  get_output (master);
  wait (NULL);
}

void
get_output (int fd)
{
#define BUFSIZE 1024
  char buf[BUFSIZE];
  int i;

  for (i = 0; i < 10; ++i)
    {
      int nread;
      nread = read (fd, buf, BUFSIZE);
      if (nread > 0)
	write (STDOUT_FILENO, buf, nread);
      else
	{
	  printf ("No more output.\n");
	  break;
	}
    }
}


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: gdb problem
  2004-01-27 14:50 RS
@ 2004-01-28  0:02 ` Christopher Faylor
  0 siblings, 0 replies; 35+ messages in thread
From: Christopher Faylor @ 2004-01-28  0:02 UTC (permalink / raw)
  To: cygwin; +Cc: rs

On Tue, Jan 27, 2004 at 02:38:28PM +0100, RS wrote:
>>Don't use CYGWIN=tty when debugging.  It confuses the debugee.
>
>First of all thank you, it really helps when I start a shell using
>"cygwin\cygwin.bat".

Ok.  So, if you want to do this, then you will observe the behavior
that you mentioned.

>But I do not understand why it helps, because gdb is a unix program and
>I thought that
>problems with tty option may occur with Windows programs.
>Another point is that I commonly use
>"cygwin\usr\X11R6\bin\startxwin.bat" to start a shell.
>Here no CYGWIN environment variable is defined. Nevertheless I have the
>problem with
>gdb in this case.

Same problem.  gdb starts the debugee in a fashion that breaks the
understanding that "this pipe that is attached to stdin/stdout/stderr is
actually a tty/pty".  So, cygwin (or MSVCRT) assumes that you are attached
to a pipe and buffers input/output accordingly.

It's possible to modify gdb to work around this but that isn't going to
help you in the short term and I have no plans on doing this in the
short to medium term.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 35+ messages in thread

* RE: gdb problem
@ 2004-01-27 14:50 RS
  2004-01-28  0:02 ` Christopher Faylor
  0 siblings, 1 reply; 35+ messages in thread
From: RS @ 2004-01-27 14:50 UTC (permalink / raw)
  To: cygwin; +Cc: rs

> Don't use CYGWIN=tty when debugging.  It confuses the debugee.
> cgf

First of all thank you, it really helps when I start a shell using
"cygwin\cygwin.bat".
But I do not understand why it helps, because gdb is a unix program and
I thought that
problems with tty option may occur with Windows programs.
Another point is that I commonly use
"cygwin\usr\X11R6\bin\startxwin.bat" to start a shell.
Here no CYGWIN environment variable is defined. Nevertheless I have the
problem with
gdb in this case.

Thank you in advance,
Robert



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: gdb problem
  2004-01-26 20:04 RS
@ 2004-01-26 20:38 ` Christopher Faylor
  0 siblings, 0 replies; 35+ messages in thread
From: Christopher Faylor @ 2004-01-26 20:38 UTC (permalink / raw)
  To: cygwin

On Mon, Jan 26, 2004 at 08:23:00PM +0100, RS wrote:
>Using gdb under cygwin I had a problem that can be demonstrated with
>following little program:
>[snip]
>Under Cygwin (Win98 and Win2k) text written to stdout is printed only
>after finishing the
>Thank you for any hint,

Don't use CYGWIN=tty when debugging.  It confuses the debugee.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 35+ messages in thread

* gdb problem
@ 2004-01-26 20:04 RS
  2004-01-26 20:38 ` Christopher Faylor
  0 siblings, 1 reply; 35+ messages in thread
From: RS @ 2004-01-26 20:04 UTC (permalink / raw)
  To: cygwin; +Cc: rs

Using gdb under cygwin I had a problem that can be demonstrated with
following
little program:

==================================
#include <stdio.h>

int main()
{
  char str[100];
  printf("Hello !\n");
  scanf("%s", str);
  printf("str: %s\n", str);
  scanf("%s", str);
  printf("str: %s\n", str);
  return -1;
}
==================================

With Linux (Debian Woody) gdb works fine:
==================================
$ gdb hello
GNU gdb 2002-04-01-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-linux"...
(gdb) r
Starting program: /home/rs/t/hello
Hello !
ttt
str: ttt
sss
str: sss

Program exited with code 0377.
==================================

Under Cygwin (Win98 and Win2k) text written to stdout is printed only
after finishing the
last input to stdin:
==================================
bash-2.05b$ gdb hello
GNU gdb 2003-09-20-cvs (cygwin-special)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) r
Starting program: /home/rs/t/hello.exe
ttt
sss
Hello !
str: ttt
str: sss

Program exited with code 0177777.
==================================

Thank you for any hint,
Robert




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 35+ messages in thread

* RE: Gdb problem
@ 2001-08-28  0:59 Wolfgang Fritz
  0 siblings, 0 replies; 35+ messages in thread
From: Wolfgang Fritz @ 2001-08-28  0:59 UTC (permalink / raw)
  To: cygwin

Did you enable debugging during compile and link (gcc option -g)?

> -----Original Message-----
> From: Jorge Goncalvez [ mailto:goncal11@col.bsf.alcatel.fr ]
> Sent: Tuesday, August 28, 2001 9:42 AM
> To: cygwin@sources.redhat.com
> Subject: Re:Gdb problem
> 
> 
> Hi, I am tring to debug a port of the iSC DHCPD under cygwin 
> but when I use Gdb 
> I only can select Assembly language instead of source code.
> Why?
> 
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 
>

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Gdb problem
  2001-08-28  0:45 problem Jorge Goncalvez
@ 2001-08-28  0:55 ` Andrew Markebo
  0 siblings, 0 replies; 35+ messages in thread
From: Andrew Markebo @ 2001-08-28  0:55 UTC (permalink / raw)
  To: Jorge Goncalvez; +Cc: cygwin

/ Jorge Goncalvez <goncal11@col.bsf.alcatel.fr> wrote:
| Hi, I am tring to debug a port of the iSC DHCPD under cygwin but when I use Gdb 
| I only can select Assembly language instead of source code.
| Why?

Did you compile the dhcpd with -g? Are the source-files available?

        /Andy

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: gdb problem
       [not found] <NFBBJHGBKLKEAOHMECHMEEDECAAA.yrwang@cc.nctu.edu.tw>
@ 2001-05-22  3:12 ` egor duda
  0 siblings, 0 replies; 35+ messages in thread
From: egor duda @ 2001-05-22  3:12 UTC (permalink / raw)
  To: Topas; +Cc: cygwin

Hi!

Tuesday, 22 May, 2001 Topas yrwang@cc.nctu.edu.tw wrote:

T> The following is the screenshot I try to use set new-console

[...]

i'd like to ask once again:

>> does your version of gdb support this option? did you turn it
>> on _before_ starting program? does new console window appears when you
>> start your test program from gdb via 'run'?

checking if your gdb supports 'set new-console' can be done by 'info set'
command.

without answers to this questions any screenshots are useless.

and please, keep replying to the list, don't e-mail me directly.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: gdb problem
  2000-06-02 10:02 ` Jonathan Larmour
@ 2000-06-02 10:03   ` Jonathan Larmour
  0 siblings, 0 replies; 35+ messages in thread
From: Jonathan Larmour @ 2000-06-02 10:03 UTC (permalink / raw)
  To: earnie_boyd; +Cc: cygwin

Jonathan Larmour wrote:
> 
> In article < 20000602132508.6938.qmail@web125.yahoomail.com > you write:
> >Purposed changes to the winsup/cygwin/path.cc source have caused a defect in
> >the tk portion of gdb.  You can see the source by using the non-windowed
> >version.
> 
> Will this be fixed in cygwin or GDB? Obviously it is highly unfortunate
> for the "stable" GDB 5 to suddently acquire such a problem.

Sorry, ignore me. I've only now seen cgf's reply (mea culpa for reading
this through news :-/ ).

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: gdb problem
  2000-06-02  6:25 Earnie Boyd
  2000-06-02  8:32 ` Chris Faylor
@ 2000-06-02 10:02 ` Jonathan Larmour
  2000-06-02 10:03   ` Jonathan Larmour
  1 sibling, 1 reply; 35+ messages in thread
From: Jonathan Larmour @ 2000-06-02 10:02 UTC (permalink / raw)
  To: earnie_boyd; +Cc: cygwin

In article < 20000602132508.6938.qmail@web125.yahoomail.com > you write:
>Purposed changes to the winsup/cygwin/path.cc source have caused a defect in
>the tk portion of gdb.  You can see the source by using the non-windowed
>version.

Will this be fixed in cygwin or GDB? Obviously it is highly unfortunate
for the "stable" GDB 5 to suddently acquire such a problem.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: gdb problem
  2000-06-02  6:25 Earnie Boyd
@ 2000-06-02  8:32 ` Chris Faylor
  2000-06-02 10:02 ` Jonathan Larmour
  1 sibling, 0 replies; 35+ messages in thread
From: Chris Faylor @ 2000-06-02  8:32 UTC (permalink / raw)
  To: Cygwin

On Fri, Jun 02, 2000 at 06:25:08AM -0700, Earnie Boyd wrote:
>Purposed changes to the winsup/cygwin/path.cc source have caused a defect in
>the tk portion of gdb.  You can see the source by using the non-windowed
>version.

I have a fix for this which I will introduce to
sourceware.cygnus.com:/pub/cygwin/latest in a few days.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: gdb problem
@ 2000-06-02  6:25 Earnie Boyd
  2000-06-02  8:32 ` Chris Faylor
  2000-06-02 10:02 ` Jonathan Larmour
  0 siblings, 2 replies; 35+ messages in thread
From: Earnie Boyd @ 2000-06-02  6:25 UTC (permalink / raw)
  To: Tom M. Yeh, Cygwin

Purposed changes to the winsup/cygwin/path.cc source have caused a defect in
the tk portion of gdb.  You can see the source by using the non-windowed
version.

Regards,
Earnie.
--- "Tom M. Yeh" <tomyeh@infoshock.com> wrote:
> I installed the latest version of Cygwin (5/15/00). When I used gdb to debug
> a program, gdb popped up a dialog saying it cannot open the source file.
> What happens? The problem is still there even I compiled a program as simple
> as "hello world".
> 
> Regards,
> Tom
> 
> Here is the stack trace.
> ----------------------------------------------
> couldn't stat "/home/tomyeh/myprj/nolib/main.c": no such file or directory
>     while executing
> "file mtime $f"
>     (object "::.srcwin0.srcwin.container.pane1.childsite.con" method
> "::SrcTextWin::_mtime_changed" body line 7)
>     invoked from within
> "_mtime_changed $filename"
>     (object "::.srcwin0.srcwin.container.pane1.childsite.con" method
> "::SrcTextWin::FillSource" body line 10)
>     invoked from within
> "FillSource t $tagname $filename $funcname $line $addr $pc_addr $lib"
>     ("SOURCE" arm line 2)
>     invoked from within
> "switch $current(mode) {
>     SOURCE {
>       FillSource t $tagname $filename $funcname $line $addr $pc_addr $lib
>     }
>     ASSEMBLY {
>       FillAssembly..."
>     (object "::.srcwin0.srcwin.container.pane1.childsite.con" method
> "::SrcTextWin::location" body line 26)
>     invoked from within
> "$twin location $tag $name $funcname $line $addr $pc_addr $lib"
>     (object "::.srcwin0.srcwin" method "::SrcWin::location" body line 52)
>     invoked from within
> "location BROWSE_TAG [list $val "" $full 0 0 0 {}]"
>     (object "::.srcwin0.srcwin" method "::SrcWin::_name" body line 22)
>     invoked from within
> "::.srcwin0.srcwin _name .srcwin0.srcwin.container.pane3.childsite.con.name
> main.c"
>     (in namespace inscope "::SrcWin" script line 1)
>     invoked from within
> "namespace inscope ::SrcWin {::.srcwin0.srcwin _name}
> ..srcwin0.srcwin.container.pane3.childsite.con.name main.c"
>     ("after" script)errorCode is POSIX ENOENT {no such file or directory}
> 
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

^ permalink raw reply	[flat|nested] 35+ messages in thread

* gdb problem
  1999-03-29 12:22 Igor Sheyn
  1999-03-29 16:45 ` Chris Faylor
@ 1999-03-31 19:45 ` Igor Sheyn
  1 sibling, 0 replies; 35+ messages in thread
From: Igor Sheyn @ 1999-03-31 19:45 UTC (permalink / raw)
  To: cygwin

Hi,

I'm running B20.1 on NT4.0.
I started gdb and tried to run a program.  Here's what I see:
------------------------------------------------------------------------
Starting program: /src/pari-2.0.15.alpha/o.cygwin_nt-4.0-i586.dbg/gp-sta.exe -q
61000000:/cygnus/CYGWIN~1/H-I586~1/bin/cygwin1.dll

[failed reading symbols from DLL]
"/WINNT/system32/advapi32.dll": error reading line numbers


[failed reading symbols from DLL]
"/WINNT/system32/KERNEL32.dll": error reading line numbers

77e70000:/WINNT/system32/USER32.dll
77ed0000:/WINNT/system32/GDI32.dll
77e10000:/WINNT/system32/RPCRT4.dll
77bf0000:/WINNT/System32/rpcltc1.dll
------------------------------------------------------------------------
Any ideas why the error?  I have full administrative rights on my PC
and am logged in locally, not into domain.

Thanks

Igor

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com


^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: gdb problem
  1999-03-29 16:45 ` Chris Faylor
@ 1999-03-31 19:45   ` Chris Faylor
  0 siblings, 0 replies; 35+ messages in thread
From: Chris Faylor @ 1999-03-31 19:45 UTC (permalink / raw)
  To: Igor Sheyn; +Cc: cygwin

On Mon, Mar 29, 1999 at 03:22:26PM -0500, Igor Sheyn wrote:
>Hi,
>
>I'm running B20.1 on NT4.0.
>I started gdb and tried to run a program.  Here's what I see:
>------------------------------------------------------------------------
>Starting program: /src/pari-2.0.15.alpha/o.cygwin_nt-4.0-i586.dbg/gp-sta.exe -q
>61000000:/cygnus/CYGWIN~1/H-I586~1/bin/cygwin1.dll
>
>[failed reading symbols from DLL]
>"/WINNT/system32/advapi32.dll": error reading line numbers
>
>
>[failed reading symbols from DLL]
>"/WINNT/system32/KERNEL32.dll": error reading line numbers
>
>77e70000:/WINNT/system32/USER32.dll
>77ed0000:/WINNT/system32/GDI32.dll
>77e10000:/WINNT/system32/RPCRT4.dll
>77bf0000:/WINNT/System32/rpcltc1.dll
>------------------------------------------------------------------------
>Any ideas why the error?  I have full administrative rights on my PC
>and am logged in locally, not into domain.

There are no line numbers in the dlls.

-chris

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com


^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: gdb problem
  1999-03-29 12:22 Igor Sheyn
@ 1999-03-29 16:45 ` Chris Faylor
  1999-03-31 19:45   ` Chris Faylor
  1999-03-31 19:45 ` Igor Sheyn
  1 sibling, 1 reply; 35+ messages in thread
From: Chris Faylor @ 1999-03-29 16:45 UTC (permalink / raw)
  To: Igor Sheyn; +Cc: cygwin

On Mon, Mar 29, 1999 at 03:22:26PM -0500, Igor Sheyn wrote:
>Hi,
>
>I'm running B20.1 on NT4.0.
>I started gdb and tried to run a program.  Here's what I see:
>------------------------------------------------------------------------
>Starting program: /src/pari-2.0.15.alpha/o.cygwin_nt-4.0-i586.dbg/gp-sta.exe -q
>61000000:/cygnus/CYGWIN~1/H-I586~1/bin/cygwin1.dll
>
>[failed reading symbols from DLL]
>"/WINNT/system32/advapi32.dll": error reading line numbers
>
>
>[failed reading symbols from DLL]
>"/WINNT/system32/KERNEL32.dll": error reading line numbers
>
>77e70000:/WINNT/system32/USER32.dll
>77ed0000:/WINNT/system32/GDI32.dll
>77e10000:/WINNT/system32/RPCRT4.dll
>77bf0000:/WINNT/System32/rpcltc1.dll
>------------------------------------------------------------------------
>Any ideas why the error?  I have full administrative rights on my PC
>and am logged in locally, not into domain.

There are no line numbers in the dlls.

-chris

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

^ permalink raw reply	[flat|nested] 35+ messages in thread

* gdb problem
@ 1999-03-29 12:22 Igor Sheyn
  1999-03-29 16:45 ` Chris Faylor
  1999-03-31 19:45 ` Igor Sheyn
  0 siblings, 2 replies; 35+ messages in thread
From: Igor Sheyn @ 1999-03-29 12:22 UTC (permalink / raw)
  To: cygwin

Hi,

I'm running B20.1 on NT4.0.
I started gdb and tried to run a program.  Here's what I see:
------------------------------------------------------------------------
Starting program: /src/pari-2.0.15.alpha/o.cygwin_nt-4.0-i586.dbg/gp-sta.exe -q
61000000:/cygnus/CYGWIN~1/H-I586~1/bin/cygwin1.dll

[failed reading symbols from DLL]
"/WINNT/system32/advapi32.dll": error reading line numbers


[failed reading symbols from DLL]
"/WINNT/system32/KERNEL32.dll": error reading line numbers

77e70000:/WINNT/system32/USER32.dll
77ed0000:/WINNT/system32/GDI32.dll
77e10000:/WINNT/system32/RPCRT4.dll
77bf0000:/WINNT/System32/rpcltc1.dll
------------------------------------------------------------------------
Any ideas why the error?  I have full administrative rights on my PC
and am logged in locally, not into domain.

Thanks

Igor

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: GDB Problem
  1997-10-29 17:22 GDB Problem Sudhakar Ganti
@ 1997-10-30  5:48 ` Chris Faylor
  0 siblings, 0 replies; 35+ messages in thread
From: Chris Faylor @ 1997-10-30  5:48 UTC (permalink / raw)
  To: gnu-win32

In article < 1.5.4.32.19971030121858.00667664@pop.ncf.carleton.ca >,
Sudhakar Ganti  <an469@freenet.carleton.ca> wrote:
>Hi,
>
>I recently intalled the GNU-Win32 package the beta 18 version. I installed
>everything as outlined (from the binaries). I have a problem with the
>gdb, both command line (-nw option) or the windows version.
>
>Specifically when I load a file and run it, the gdb says that
>it has failed reading the symbols from DLLs: shlwapi.dll and comctl32.dll.
>Then the programs runs OK. But when I quit gdb, the DOS window is not closed
>and the Windows95 reports an error message "GDB casued an invalid
>page fault in cw3215.dll". At this point I cannot even close the DOS
>window, as well I cannot shut down Windows95. This is all from commandline
>with -nw option. If I run the gdb with the windows (no -nw option) it shows 
>the windows, but when I try to load any file and run, it hangs.
>
>I looked in the mail archives and did not find any queries
>regarding this. Any help will be appreciated.

I have roughly the same problem on Windows NT and Windows 95.  It is a real
pain when the entire machine hangs and you have to power cycle to continue.
This is obviously a Windows design bug but it is annoying that GDB exercises
it.

The only way I've found around this problem is to always let the debugged
process run to completion and to never use 'q' in gdb.  Always kill the
gdb process from another process or from the Task Manager.  If you can't
let the debugged process run to completion then you can kill it also.

This seems to work 80% of the time at least.
-- 
http://www.bbc.com/	cgf@bbc.com			"Strange how unreal
VMS=>UNIX Solutions	Boston Business Computing	 the real can be."
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 35+ messages in thread

* GDB Problem
@ 1997-10-29 17:22 Sudhakar Ganti
  1997-10-30  5:48 ` Chris Faylor
  0 siblings, 1 reply; 35+ messages in thread
From: Sudhakar Ganti @ 1997-10-29 17:22 UTC (permalink / raw)
  To: gnu-win32

Hi,

I recently intalled the GNU-Win32 package the beta 18 version. I installed
everything as outlined (from the binaries). I have a problem with the
gdb, both command line (-nw option) or the windows version.

Specifically when I load a file and run it, the gdb says that
it has failed reading the symbols from DLLs: shlwapi.dll and comctl32.dll.
Then the programs runs OK. But when I quit gdb, the DOS window is not closed
and the Windows95 reports an error message "GDB casued an invalid
page fault in cw3215.dll". At this point I cannot even close the DOS
window, as well I cannot shut down Windows95. This is all from commandline
with -nw option. If I run the gdb with the windows (no -nw option) it shows 
the windows, but when I try to load any file and run, it hangs.

I looked in the mail archives and did not find any queries
regarding this. Any help will be appreciated.

-Sudhakar
    __o      __o                       
--_`\<-_---_`\<-_-------Sudhakar Ganti------------
 (_)/ (_) (_)/ (_)    Nepean, Ontario, Canada   
--------------------------------------------------

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 35+ messages in thread

* GDB Problem
@ 1997-09-24  6:57 Bardley09
  0 siblings, 0 replies; 35+ messages in thread
From: Bardley09 @ 1997-09-24  6:57 UTC (permalink / raw)
  To: gnu-win32

GDB can't find main.tcl (and crashes on exit, apparently harmlessly) despite
the fact that it's there and the env variable is set up correctly with
forward slashes:

GDBTK_LIBRARY= C:/gnuwin32/b18/share/gdbtcl

I noticed in the faq (or was it the readme file) it says it should be 'tcl'
instead of 'gdbtcl'.  I assumed this wasn't right.  I'm using W95.  Any help
on this will be much appreciated.  Oh, and the rest of my environment is
correctly set up as far as i know....

Thank you.


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: GDB problem
@ 1997-07-09  5:31 Bryan Rosenburg
  0 siblings, 0 replies; 35+ messages in thread
From: Bryan Rosenburg @ 1997-07-09  5:31 UTC (permalink / raw)
  To: gnu-win32; +Cc: noer, shebs

I wrote:
> On four of our Windows-95 machines, a simple "gdb -nw" followed
> by "quit" results in an "illegal operation" error but has no other ill
> effects.  But on the fifth machine, the same sequence consistently
results
> in gdb hanging in an unkillable state and consuming 90% or more of the
CPU.

The gdb hanging problem turned out to be of our own making.  On the problem
machine we had a "default application debugger" (not gdb) installed, but
the
debugger was misconfigured.  When gdb generated its illegal operation on
exit
(which it always does), the system went into a loop trying to invoke the
debugger executable which wasn't where it was supposed to be.  With no
default debugger installed, gdb's illegal operation on exit is benign.

With this problem solved, gdb in b18 has been quite stable and useful.

Bryan Rosenburg
rosnbrg@watson.ibm.com


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: GDB problem
@ 1997-07-08  6:58 Bryan Rosenburg
  0 siblings, 0 replies; 35+ messages in thread
From: Bryan Rosenburg @ 1997-07-08  6:58 UTC (permalink / raw)
  To: noer; +Cc: hamann, gnu-win32

Geoffrey Noer writes:
> My main problem with the gdb in beta 18 is the crash on exit
> problem.  I hope it will be fixed in future releases...
and:
> My consistent problem is quitting the tcl/tk gdb (I believe the problem
> is actually in tcl/tk rather than in gdb).  That said, I find the b18 gdb
> to be fairly usable so you may not need to completely abandon using it
> because of this problem.

In my group, gdb is "fairly usable" on some machines but not on others, and
the problem seems to be independent of whether or not we use the tcl/tk
front end.  On four of our Windows-95 machines, a simple "gdb -nw" followed
by "quit" results in an "illegal operation" error but has no other ill
effects.  But on the fifth machine, the same sequence consistently results
in gdb hanging in an unkillable state and consuming 90% or more of the CPU.
Killing it manually using ctrl-alt-del gets it out of the Close Program
dialog, but the CPU is still saturated and wintop (from Microsoft's
Kernel Toys) shows GDB.EXE to still be consuming all the cycles it can get.
We've found no way to recover short of rebooting.

We're running b18 with Sergey's May26 patch.  (The patch has no effect on
this problem).  On two Windows-NT boxes with the same setup, gdb runs
without error.

This problem has become a serious obstacle for us.  Any suggestions, fixes,
or workarounds would be most welcome.

Bryan Rosenburg
rosnbrg@watson.ibm.com


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: GDB problem
  1997-07-08  0:56       ` Geoffrey Noer
@ 1997-07-08  6:58         ` Stuart Williams
  0 siblings, 0 replies; 35+ messages in thread
From: Stuart Williams @ 1997-07-08  6:58 UTC (permalink / raw)
  To: Geoffrey Noer; +Cc: J.R. Dean, gnu-win32

[-- Attachment #1: Type: text/plain, Size: 4148 bytes --]

I have tracked down a few problems that cause GDB to bail out,
some related to memory allocation/deallocation. I have (re-)build
i386-cygwin32-gdb.exe and m68000-coff-gdb.exe with these patches applied
which has greatly improved their stability. 

I hope they help.

Regards

Stuart Williams
HP Labs, Bristol

I sent a the patches that we applied to Geof a little while back,
but

Geoffrey Noer wrote:
> 
> J.R. Dean wrote:
> >
> > >My main problem with the gdb in beta 18 is the crash on exit
> > >problem.  I hope it will be fixed in future releases...
> >
> > Oh, so it *is* a bug?  Whoops.
> >
> > Well, so much for debugging with gdb.
> 
> My consistent problem is quitting the tcl/tk gdb (I believe the problem
> is actually in tcl/tk rather than in gdb).  That said, I find the b18 gdb
> to be fairly usable so you may not need to completely abandon using it
> because of this problem.
> 
> --
> Geoffrey Noer
> noer@cygnus.com
> -
> For help on using this list (especially unsubscribing), send a message to
> "gnu-win32-request@cygnus.com" with one line of text: "help".

----------
From:   Stuart Williams[SMTP:skw@hplb.hpl.hp.com]
Sent:   02 June 1997 15:51
To:     'Geoffrey Noer'
Subject:        GDB Problems/Fixs

Geof,

I've been building GNU Win32 to cross develop on 68k from a Win32
platform.
I was pleased to see that GDB has been ported to support the Tk/Tcl UI
under
Win32. We had enormous problems trying to build and use the windows
based 
gdb in the mswin subdirectory. Functionally at least, the Tk/Tcl based
GDB is
a big improvement. 

To get things working properly I had to patch a couple of files. In
gdbtk.c some
of the Tcl_ function calls return dynamically allocated structures that
are then
subsequently free'ed. Unfortunately the allocation happens within the
Tk/Tcl
DLL while the freeing does not. For example, things go bang (well
abort())
at the free in 'gdbtk_query' when it frees 'command'. Try it... if you
do something
that throws a query, gdb.exe (the one in the binary distribution) exits
without 
warning. 'free' calls 'mfree' which in turn checks for magic value
before and after
the allocated memory region. However, they're not there because the
allocation
was done within a call to 'Tcl_Merge'.

I've fixed this by '#ifdef WINNT' around the Tcl_Alloc and Tcl_Free
definitions (I have
no idea how the Tk/Tcl DLL is expected to call them) and #ifdef'd around
the 'free'
calls to substitute Tcl_Free which now resolves through libtcl7.6.a to
the DLL.
Result... no bang.

Later hit a second problem (don't recall the symptom now) that turned
out to be
a SEGV due to chasing a null pointer in 'infcmd.c'. I suspect there are
more of
these to find!

Attached are my gdbtk.c and infcmd.c and corresponding diff files. I
still have an
intermitent and annoying SEGV that occurs when GDB exits under win 95. I
haven't
tracked it down yet, but the report is:

        GDB caused an invalid page fault in
        module CW3215.DLL at 0137:005e3f66.
        Registers:
        EAX=0280fffc CS=0137 EIP=005e3f66 EFLGS=00010203
        EBX=0492fc08 SS=013f ESP=0492fbfc EBP=0492fc28
        ECX=00000001 DS=013f ESI=00000000 FS=3bef
        EDX=00000020 ES=013f EDI=0060002c GS=0000
        Bytes at CS:EIP:
        8b 00 89 43 1c 64 67 a1 00 00 89 03 64 67 89 1e 

Looks like it happens between the 'exit() call and the end of the
program.

Anyway, I hope that you can use these fixes next time around.

Regards

Stuart Williams
HP Labs, Bristol, UK.
*** infcmd.c	Tue May 20 19:00:08 1997
--- infcmd.c.orig	Tue May 20 18:59:04 1997
***************
*** 443,450 ****
  	}
      }
    fixup_symbol_section (sfn, 0);
!   if (sfn!=NULL &&
!       section_is_overlay (SYMBOL_BFD_SECTION (sfn)) && 
        !section_is_mapped (SYMBOL_BFD_SECTION (sfn)))
      {
        if (!query ("WARNING!!!  Destination is in unmapped overlay!  Jump anyway? "))
--- 443,449 ----
  	}
      }
    fixup_symbol_section (sfn, 0);
!   if (section_is_overlay (SYMBOL_BFD_SECTION (sfn)) && 
        !section_is_mapped (SYMBOL_BFD_SECTION (sfn)))
      {
        if (!query ("WARNING!!!  Destination is in unmapped overlay!  Jump anyway? "))

[-- Attachment #2: gdbtk.c --]
[-- Type: text/x-c, Size: 38012 bytes --]

/* Tcl/Tk interface routines.
   Copyright 1994, 1995, 1996, 1997 Free Software Foundation, Inc.

   Written by Stu Grossman <grossman@cygnus.com> of Cygnus Support.

This file is part of GDB.

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */

#include "defs.h"
#include "symtab.h"
#include "inferior.h"
#include "command.h"
#include "bfd.h"
#include "symfile.h"
#include "objfiles.h"
#include "target.h"
#include <tcl.h>
#include <tk.h>
/* #include <itcl.h> */
#ifdef ANSI_PROTOTYPES
#include <stdarg.h>
#else
#include <varargs.h>
#endif
#include <signal.h>
#include <fcntl.h>
#include <unistd.h>
#include <setjmp.h>
#include "top.h"
#include <sys/ioctl.h>
#include "gdb_string.h"
#include "dis-asm.h"
#include <stdio.h>
#include "gdbcmd.h"

#ifndef WINNT
#ifndef FIOASYNC
#include <sys/stropts.h>
#endif
#endif

#ifdef WINNT
#define GDBTK_PATH_SEP ";"
#else
#define GDBTK_PATH_SEP ":"
#endif

/* Some versions (1.3.79, 1.3.81) of Linux don't support SIOCSPGRP the way
   gdbtk wants to use it... */
#ifdef __linux__
#undef SIOCSPGRP
#endif

static void null_routine PARAMS ((int));
static void gdbtk_flush PARAMS ((FILE *));
static void gdbtk_fputs PARAMS ((const char *, FILE *));
static int gdbtk_query PARAMS ((const char *, va_list));
static char *gdbtk_readline PARAMS ((char *));
static void gdbtk_init PARAMS ((void));
static void tk_command_loop PARAMS ((void));
static void gdbtk_call_command PARAMS ((struct cmd_list_element *, char *, int));
static int gdbtk_wait PARAMS ((int, struct target_waitstatus *));
static void x_event PARAMS ((int));
static void gdbtk_interactive PARAMS ((void));
static void cleanup_init PARAMS ((int));
static void tk_command PARAMS ((char *, int));
static int gdb_disassemble PARAMS ((ClientData, Tcl_Interp *, int, char *[]));
static int compare_lines PARAMS ((const PTR, const PTR));
static int gdbtk_dis_asm_read_memory PARAMS ((bfd_vma, bfd_byte *, int, disassemble_info *));
static int gdb_path_conv PARAMS ((ClientData, Tcl_Interp *, int, char *[]));
static int gdb_stop PARAMS ((ClientData, Tcl_Interp *, int, char *[]));
static int gdb_listfiles PARAMS ((ClientData, Tcl_Interp *, int, char *[]));
static int call_wrapper PARAMS ((ClientData, Tcl_Interp *, int, char *[]));
static int gdb_cmd PARAMS ((ClientData, Tcl_Interp *, int, char *argv[]));
static int gdb_fetch_registers PARAMS ((ClientData, Tcl_Interp *, int, char *[]));
static void gdbtk_readline_end PARAMS ((void));
static int gdb_changed_register_list PARAMS ((ClientData, Tcl_Interp *, int, char *[]));
static void register_changed_p PARAMS ((int, void *));
static int gdb_get_breakpoint_list PARAMS ((ClientData, Tcl_Interp *, int, char *[]));
static int gdb_get_breakpoint_info PARAMS ((ClientData, Tcl_Interp *, int, char *[]));
static void breakpoint_notify PARAMS ((struct breakpoint *, const char *));
static void gdbtk_create_breakpoint PARAMS ((struct breakpoint *));
static void gdbtk_delete_breakpoint PARAMS ((struct breakpoint *));
static void gdbtk_modify_breakpoint PARAMS ((struct breakpoint *));
static int gdb_loc PARAMS ((ClientData, Tcl_Interp *, int, char *[]));
static int gdb_eval PARAMS ((ClientData, Tcl_Interp *, int, char *[]));
static int gdb_sourcelines PARAMS ((ClientData, Tcl_Interp *, int, char *[]));
static int map_arg_registers PARAMS ((int, char *[], void (*) (int, void *), void *));
static void get_register_name PARAMS ((int, void *));
static int gdb_regnames PARAMS ((ClientData, Tcl_Interp *, int, char *[]));
static void get_register PARAMS ((int, void *));

/* Handle for TCL interpreter */

static Tcl_Interp *interp = NULL;

static int x_fd;		/* X network socket */

/* This variable is true when the inferior is running.  Although it's
   possible to disable most input from widgets and thus prevent
   attempts to do anything while the inferior is running, any commands
   that get through - even a simple memory read - are Very Bad, and
   may cause GDB to crash or behave strangely.  So, this variable
   provides an extra layer of defense.  */

static int running_now;

/* This variable determines where memory used for disassembly is read from.
   If > 0, then disassembly comes from the exec file rather than the
   target (which might be at the other end of a slow serial link).  If
   == 0 then disassembly comes from target.  If < 0 disassembly is
   automatically switched to the target if it's an inferior process,
   otherwise the exec file is used.  */

static int disassemble_from_exec = -1;

static char *Gdbtk_Library;

#ifndef WINNT
/* Supply malloc calls for tcl/tk.  */

char *
Tcl_Alloc (size)
     unsigned int size;
{
  return xmalloc (size);
}

char *
Tcl_Realloc (ptr, size)
     char *ptr;
     unsigned int size;
{
  return xrealloc (ptr, size);
}

void
Tcl_Free(ptr)
     char *ptr;
{
  free (ptr);
}

#endif

static void
null_routine(arg)
     int arg;
{
}

/* The following routines deal with stdout/stderr data, which is created by
   {f}printf_{un}filtered and friends.  gdbtk_fputs and gdbtk_flush are the
   lowest level of these routines and capture all output from the rest of GDB.
   Normally they present their data to tcl via callbacks to the following tcl
   routines:  gdbtk_tcl_fputs, gdbtk_tcl_fputs_error, and gdbtk_flush.  These
   in turn call tk routines to update the display.

   Under some circumstances, you may want to collect the output so that it can
   be returned as the value of a tcl procedure.  This can be done by
   surrounding the output routines with calls to start_saving_output and
   finish_saving_output.  The saved data can then be retrieved with
   get_saved_output (but this must be done before the call to
   finish_saving_output).  */

/* Dynamic string header for stdout. */

static Tcl_DString *result_ptr;
\f
static void
gdbtk_flush (stream)
     FILE *stream;
{
#if 0
  /* Force immediate screen update */

  Tcl_VarEval (interp, "gdbtk_tcl_flush", NULL);
#endif
}

static void
gdbtk_fputs (ptr, stream)
     const char *ptr;
     FILE *stream;
{

  if (result_ptr)
    Tcl_DStringAppend (result_ptr, (char *)ptr, -1);
  else
    {
      Tcl_DString str;

      Tcl_DStringInit (&str);

      Tcl_DStringAppend (&str, "gdbtk_tcl_fputs", -1);
      Tcl_DStringAppendElement (&str, (char *)ptr);

      Tcl_Eval (interp, Tcl_DStringValue (&str));
      Tcl_DStringFree (&str);
    }
}

static int
gdbtk_query (query, args)
     const char *query;
     va_list args;
{
  char buf[200], *merge[2];
  char *command;
  long val;

  vsprintf (buf, query, args);
  merge[0] = "gdbtk_tcl_query";
  merge[1] = buf;
  command = Tcl_Merge (2, merge);
  Tcl_Eval (interp, command);

#ifndef WINNT
  free (command);
#else
  Tcl_Free (command);
#endif


  val = atol (interp->result);
  return val;
}

/* VARARGS */
static void
#ifdef ANSI_PROTOTYPES
gdbtk_readline_begin (char *format, ...)
#else
gdbtk_readline_begin (va_alist)
     va_dcl
#endif
{
  va_list args;
  char buf[200], *merge[2];
  char *command;

#ifdef ANSI_PROTOTYPES
  va_start (args, format);
#else
  char *format;
  va_start (args);
  format = va_arg (args, char *);
#endif

  vsprintf (buf, format, args);
  merge[0] = "gdbtk_tcl_readline_begin";
  merge[1] = buf;
  command = Tcl_Merge (2, merge);
  Tcl_Eval (interp, command);
#ifndef WINNT
  free (command);
#else
  Tcl_Free (command);
#endif
}

static char *
gdbtk_readline (prompt)
     char *prompt;
{
  char *merge[2];
  char *command;
  int result;

  merge[0] = "gdbtk_tcl_readline";
  merge[1] = prompt;
  command = Tcl_Merge (2, merge);
  result = Tcl_Eval (interp, command);

#ifndef WINNT
  free (command);
#else
  Tcl_Free (command);
#endif

  if (result == TCL_OK)
    {
      return (strdup (interp -> result));
    }
  else
    {
      gdbtk_fputs (interp -> result, gdb_stdout);
      gdbtk_fputs ("\n", gdb_stdout);
      return (NULL);
    }
}

static void
gdbtk_readline_end ()
{
  Tcl_Eval (interp, "gdbtk_tcl_readline_end");
}

\f
static void
#ifdef ANSI_PROTOTYPES
dsprintf_append_element (Tcl_DString *dsp, char *format, ...)
#else
dsprintf_append_element (va_alist)
     va_dcl
#endif
{
  va_list args;
  char buf[1024];

#ifdef ANSI_PROTOTYPES
  va_start (args, format);
#else
  Tcl_DString *dsp;
  char *format;

  va_start (args);
  dsp = va_arg (args, Tcl_DString *);
  format = va_arg (args, char *);
#endif

  vsprintf (buf, format, args);

  Tcl_DStringAppendElement (dsp, buf);
}

static int
gdb_path_conv (clientData, interp, argc, argv)
     ClientData clientData;
     Tcl_Interp *interp;
     int argc;
     char *argv[];
{
#ifdef WINNT
  char pathname[256], *ptr;
  if (argc != 2)
    error ("wrong # args");
  cygwin32_conv_to_full_win32_path (argv[1], pathname);
  for (ptr = pathname; *ptr; ptr++)
    {
      if (*ptr == '\\')
	*ptr = '/';
    }
#else
  char *pathname = argv[1];
#endif
  Tcl_DStringAppend (result_ptr, pathname, strlen(pathname));
  return TCL_OK;
}

static int
gdb_get_breakpoint_list (clientData, interp, argc, argv)
     ClientData clientData;
     Tcl_Interp *interp;
     int argc;
     char *argv[];
{
  struct breakpoint *b;
  extern struct breakpoint *breakpoint_chain;

  if (argc != 1)
    error ("wrong # args");

  for (b = breakpoint_chain; b; b = b->next)
    if (b->type == bp_breakpoint)
      dsprintf_append_element (result_ptr, "%d", b->number);

  return TCL_OK;
}

static int
gdb_get_breakpoint_info (clientData, interp, argc, argv)
     ClientData clientData;
     Tcl_Interp *interp;
     int argc;
     char *argv[];
{
  struct symtab_and_line sal;
  static char *bptypes[] = {"breakpoint", "hardware breakpoint", "until",
			      "finish", "watchpoint", "hardware watchpoint",
			      "read watchpoint", "access watchpoint",
			      "longjmp", "longjmp resume", "step resume",
			      "through sigtramp", "watchpoint scope",
			      "call dummy" };
  static char *bpdisp[] = {"delete", "disable", "donttouch"};
  struct command_line *cmd;
  int bpnum;
  struct breakpoint *b;
  extern struct breakpoint *breakpoint_chain;

  if (argc != 2)
    error ("wrong # args");

  bpnum = atoi (argv[1]);

  for (b = breakpoint_chain; b; b = b->next)
    if (b->number == bpnum)
      break;

  if (!b || b->type != bp_breakpoint)
    error ("Breakpoint #%d does not exist", bpnum);

  sal = find_pc_line (b->address, 0);

  Tcl_DStringAppendElement (result_ptr, symtab_to_filename (sal.symtab));
  dsprintf_append_element (result_ptr, "%d", sal.line);
  dsprintf_append_element (result_ptr, "0x%lx", b->address);
  Tcl_DStringAppendElement (result_ptr, bptypes[b->type]);
  Tcl_DStringAppendElement (result_ptr, b->enable == enabled ? "1" : "0");
  Tcl_DStringAppendElement (result_ptr, bpdisp[b->disposition]);
  dsprintf_append_element (result_ptr, "%d", b->silent);
  dsprintf_append_element (result_ptr, "%d", b->ignore_count);

  Tcl_DStringStartSublist (result_ptr);
  for (cmd = b->commands; cmd; cmd = cmd->next)
    Tcl_DStringAppendElement (result_ptr, cmd->line);
  Tcl_DStringEndSublist (result_ptr);

  Tcl_DStringAppendElement (result_ptr, b->cond_string);

  dsprintf_append_element (result_ptr, "%d", b->thread);
  dsprintf_append_element (result_ptr, "%d", b->hit_count);

  return TCL_OK;
}

static void
breakpoint_notify(b, action)
     struct breakpoint *b;
     const char *action;
{
  char buf[100];
  int v;

  if (b->type != bp_breakpoint)
    return;

  /* We ensure that ACTION contains no special Tcl characters, so we
     can do this.  */
  sprintf (buf, "gdbtk_tcl_breakpoint %s %d", action, b->number);

  v = Tcl_Eval (interp, buf);

  if (v != TCL_OK)
    {
      gdbtk_fputs (interp->result, gdb_stdout);
      gdbtk_fputs ("\n", gdb_stdout);
    }
}

static void
gdbtk_create_breakpoint(b)
     struct breakpoint *b;
{
  breakpoint_notify (b, "create");
}

static void
gdbtk_delete_breakpoint(b)
     struct breakpoint *b;
{
  breakpoint_notify (b, "delete");
}

static void
gdbtk_modify_breakpoint(b)
     struct breakpoint *b;
{
  breakpoint_notify (b, "modify");
}
\f
/* This implements the TCL command `gdb_loc', which returns a list consisting
   of the source and line number associated with the current pc. */

static int
gdb_loc (clientData, interp, argc, argv)
     ClientData clientData;
     Tcl_Interp *interp;
     int argc;
     char *argv[];
{
  char *filename;
  struct symtab_and_line sal;
  char *funcname;
  CORE_ADDR pc;

  if (argc == 1)
    {
      pc = selected_frame ? selected_frame->pc : stop_pc;
      sal = find_pc_line (pc, 0);
    }
  else if (argc == 2)
    {
      struct symtabs_and_lines sals;
      int nelts;

      sals = decode_line_spec (argv[1], 1);

      nelts = sals.nelts;
      sal = sals.sals[0];
      free (sals.sals);

      if (sals.nelts != 1)
	error ("Ambiguous line spec");

      pc = sal.pc;
    }
  else
    error ("wrong # args");

  if (sal.symtab)
    Tcl_DStringAppendElement (result_ptr, sal.symtab->filename);
  else
    Tcl_DStringAppendElement (result_ptr, "");

  find_pc_partial_function (pc, &funcname, NULL, NULL);
  Tcl_DStringAppendElement (result_ptr, funcname);

  filename = symtab_to_filename (sal.symtab);
  Tcl_DStringAppendElement (result_ptr, filename);

  dsprintf_append_element (result_ptr, "%d", sal.line); /* line number */

  dsprintf_append_element (result_ptr, "0x%s", paddr_nz(pc)); /* PC */

  return TCL_OK;
}
\f
/* This implements the TCL command `gdb_eval'. */

static int
gdb_eval (clientData, interp, argc, argv)
     ClientData clientData;
     Tcl_Interp *interp;
     int argc;
     char *argv[];
{
  struct expression *expr;
  struct cleanup *old_chain;
  value_ptr val;

  if (argc != 2)
    error ("wrong # args");

  expr = parse_expression (argv[1]);

  old_chain = make_cleanup (free_current_contents, &expr);

  val = evaluate_expression (expr);

  val_print (VALUE_TYPE (val), VALUE_CONTENTS (val), VALUE_ADDRESS (val),
	     gdb_stdout, 0, 0, 0, 0);

  do_cleanups (old_chain);

  return TCL_OK;
}
\f
/* This implements the TCL command `gdb_sourcelines', which returns a list of
   all of the lines containing executable code for the specified source file
   (ie: lines where you can put breakpoints). */

static int
gdb_sourcelines (clientData, interp, argc, argv)
     ClientData clientData;
     Tcl_Interp *interp;
     int argc;
     char *argv[];
{
  struct symtab *symtab;
  struct linetable_entry *le;
  int nlines;

  if (argc != 2)
    error ("wrong # args");

  symtab = lookup_symtab (argv[1]);

  if (!symtab)
    error ("No such file");

  /* If there's no linetable, or no entries, then we are done. */

  if (!symtab->linetable
      || symtab->linetable->nitems == 0)
    {
      Tcl_DStringAppendElement (result_ptr, "");
      return TCL_OK;
    }

  le = symtab->linetable->item;
  nlines = symtab->linetable->nitems;

  for (;nlines > 0; nlines--, le++)
    {
      /* If the pc of this line is the same as the pc of the next line, then
	 just skip it.  */
      if (nlines > 1
	  && le->pc == (le + 1)->pc)
	continue;

      dsprintf_append_element (result_ptr, "%d", le->line);
    }

  return TCL_OK;
}
\f
static int
map_arg_registers (argc, argv, func, argp)
     int argc;
     char *argv[];
     void (*func) PARAMS ((int regnum, void *argp));
     void *argp;
{
  int regnum;

  /* Note that the test for a valid register must include checking the
     reg_names array because NUM_REGS may be allocated for the union of the
     register sets within a family of related processors.  In this case, the
     trailing entries of reg_names will change depending upon the particular
     processor being debugged.  */

  if (argc == 0)		/* No args, just do all the regs */
    {
      for (regnum = 0;
	   regnum < NUM_REGS
	   && reg_names[regnum] != NULL
	   && *reg_names[regnum] != '\000';
	   regnum++)
	func (regnum, argp);

      return TCL_OK;
    }

  /* Else, list of register #s, just do listed regs */
  for (; argc > 0; argc--, argv++)
    {
      regnum = atoi (*argv);

      if (regnum >= 0
	  && regnum < NUM_REGS
	  && reg_names[regnum] != NULL
	  && *reg_names[regnum] != '\000')
	func (regnum, argp);
      else
	error ("bad register number");
    }

  return TCL_OK;
}

static void
get_register_name (regnum, argp)
     int regnum;
     void *argp;		/* Ignored */
{
  Tcl_DStringAppendElement (result_ptr, reg_names[regnum]);
}

/* This implements the TCL command `gdb_regnames', which returns a list of
   all of the register names. */

static int
gdb_regnames (clientData, interp, argc, argv)
     ClientData clientData;
     Tcl_Interp *interp;
     int argc;
     char *argv[];
{
  argc--;
  argv++;

  return map_arg_registers (argc, argv, get_register_name, NULL);
}

#ifndef REGISTER_CONVERTIBLE
#define REGISTER_CONVERTIBLE(x) (0 != 0)
#endif

#ifndef REGISTER_CONVERT_TO_VIRTUAL
#define REGISTER_CONVERT_TO_VIRTUAL(x, y, z, a)
#endif

#ifndef INVALID_FLOAT
#define INVALID_FLOAT(x, y) (0 != 0)
#endif

static void
get_register (regnum, fp)
     int regnum;
     void *fp;
{
  char raw_buffer[MAX_REGISTER_RAW_SIZE];
  char virtual_buffer[MAX_REGISTER_VIRTUAL_SIZE];
  int format = (int)fp;

  if (read_relative_register_raw_bytes (regnum, raw_buffer))
    {
      Tcl_DStringAppendElement (result_ptr, "Optimized out");
      return;
    }

  /* Convert raw data to virtual format if necessary.  */

  if (REGISTER_CONVERTIBLE (regnum))
    {
      REGISTER_CONVERT_TO_VIRTUAL (regnum, REGISTER_VIRTUAL_TYPE (regnum),
				   raw_buffer, virtual_buffer);
    }
  else
    memcpy (virtual_buffer, raw_buffer, REGISTER_VIRTUAL_SIZE (regnum));

  if (format == 'r')
    {
      int j;
      printf_filtered ("0x");
      for (j = 0; j < REGISTER_RAW_SIZE (regnum); j++)
	{
	  register int idx = TARGET_BYTE_ORDER == BIG_ENDIAN ? j
	    : REGISTER_RAW_SIZE (regnum) - 1 - j;
	  printf_filtered ("%02x", (unsigned char)raw_buffer[idx]);
	}
    }
  else
    val_print (REGISTER_VIRTUAL_TYPE (regnum), virtual_buffer, 0,
	       gdb_stdout, format, 1, 0, Val_pretty_default);

  Tcl_DStringAppend (result_ptr, " ", -1);
}

static int
gdb_fetch_registers (clientData, interp, argc, argv)
     ClientData clientData;
     Tcl_Interp *interp;
     int argc;
     char *argv[];
{
  int format;

  if (argc < 2)
    error ("wrong # args");

  argc--;
  argv++;

  argc--;
  format = **argv++;

  return map_arg_registers (argc, argv, get_register, (void *) format);
}

/* This contains the previous values of the registers, since the last call to
   gdb_changed_register_list.  */

static char old_regs[REGISTER_BYTES];

static void
register_changed_p (regnum, argp)
     int regnum;
     void *argp;		/* Ignored */
{
  char raw_buffer[MAX_REGISTER_RAW_SIZE];

  if (read_relative_register_raw_bytes (regnum, raw_buffer))
    return;

  if (memcmp (&old_regs[REGISTER_BYTE (regnum)], raw_buffer,
	      REGISTER_RAW_SIZE (regnum)) == 0)
    return;

  /* Found a changed register.  Save new value and return its number. */

  memcpy (&old_regs[REGISTER_BYTE (regnum)], raw_buffer,
	  REGISTER_RAW_SIZE (regnum));

  dsprintf_append_element (result_ptr, "%d", regnum);
}

static int
gdb_changed_register_list (clientData, interp, argc, argv)
     ClientData clientData;
     Tcl_Interp *interp;
     int argc;
     char *argv[];
{
  argc--;
  argv++;

  return map_arg_registers (argc, argv, register_changed_p, NULL);
}
\f
/* This implements the TCL command `gdb_cmd', which sends its argument into
   the GDB command scanner.  */

static int
gdb_cmd (clientData, interp, argc, argv)
     ClientData clientData;
     Tcl_Interp *interp;
     int argc;
     char *argv[];
{
  if (argc != 2)
    error ("wrong # args");

  if (running_now)
    return TCL_OK;

  execute_command (argv[1], 1);

  bpstat_do_actions (&stop_bpstat);

  return TCL_OK;
}

/* This routine acts as a top-level for all GDB code called by tcl/Tk.  It
   handles cleanups, and calls to return_to_top_level (usually via error).
   This is necessary in order to prevent a longjmp out of the bowels of Tk,
   possibly leaving things in a bad state.  Since this routine can be called
   recursively, it needs to save and restore the contents of the jmp_buf as
   necessary.  */

static int
call_wrapper (clientData, interp, argc, argv)
     ClientData clientData;
     Tcl_Interp *interp;
     int argc;
     char *argv[];
{
  int val;
  struct cleanup *saved_cleanup_chain;
  Tcl_CmdProc *func;
  jmp_buf saved_error_return;
  Tcl_DString result, *old_result_ptr;

  Tcl_DStringInit (&result);
  old_result_ptr = result_ptr;
  result_ptr = &result;

  func = (Tcl_CmdProc *)clientData;
  memcpy (saved_error_return, error_return, sizeof (jmp_buf));

  saved_cleanup_chain = save_cleanups ();

  if (!setjmp (error_return))
    val = func (clientData, interp, argc, argv);
  else
    {
      val = TCL_ERROR;		/* Flag an error for TCL */

      gdb_flush (gdb_stderr);	/* Flush error output */

      gdb_flush (gdb_stdout);	/* Sometimes error output comes here as well */

      /* In case of an error, we may need to force the GUI into idle
	 mode because gdbtk_call_command may have bombed out while in
	 the command routine.  */

      running_now = 0;
      Tcl_Eval (interp, "gdbtk_tcl_idle");
    }

  do_cleanups (ALL_CLEANUPS);

  restore_cleanups (saved_cleanup_chain);

  memcpy (error_return, saved_error_return, sizeof (jmp_buf));

  Tcl_DStringResult (interp, &result);
  result_ptr = old_result_ptr;

  return val;
}

static int
gdb_listfiles (clientData, interp, argc, argv)
     ClientData clientData;
     Tcl_Interp *interp;
     int argc;
     char *argv[];
{
  struct objfile *objfile;
  struct partial_symtab *psymtab;
  struct symtab *symtab;

  ALL_PSYMTABS (objfile, psymtab)
    Tcl_DStringAppendElement (result_ptr, psymtab->filename);

  ALL_SYMTABS (objfile, symtab)
    Tcl_DStringAppendElement (result_ptr, symtab->filename);

  return TCL_OK;
}

static int
gdb_stop (clientData, interp, argc, argv)
     ClientData clientData;
     Tcl_Interp *interp;
     int argc;
     char *argv[];
{
  target_stop ();

  return TCL_OK;
}
\f
/* This implements the TCL command `gdb_disassemble'.  */

static int
gdbtk_dis_asm_read_memory (memaddr, myaddr, len, info)
     bfd_vma memaddr;
     bfd_byte *myaddr;
     int len;
     disassemble_info *info;
{
  extern struct target_ops exec_ops;
  int res;

  errno = 0;
  res = xfer_memory (memaddr, myaddr, len, 0, &exec_ops);

  if (res == len)
    return 0;
  else
    if (errno == 0)
      return EIO;
    else
      return errno;
}

/* We need a different sort of line table from the normal one cuz we can't
   depend upon implicit line-end pc's for lines.  This is because of the
   reordering we are about to do.  */

struct my_line_entry {
  int line;
  CORE_ADDR start_pc;
  CORE_ADDR end_pc;
};

static int
compare_lines (mle1p, mle2p)
     const PTR mle1p;
     const PTR mle2p;
{
  struct my_line_entry *mle1, *mle2;
  int val;

  mle1 = (struct my_line_entry *) mle1p;
  mle2 = (struct my_line_entry *) mle2p;

  val =  mle1->line - mle2->line;

  if (val != 0)
    return val;

  return mle1->start_pc - mle2->start_pc;
}

static int
gdb_disassemble (clientData, interp, argc, argv)
     ClientData clientData;
     Tcl_Interp *interp;
     int argc;
     char *argv[];
{
  CORE_ADDR pc, low, high;
  int mixed_source_and_assembly;
  static disassemble_info di;
  static int di_initialized;

  if (! di_initialized)
    {
      INIT_DISASSEMBLE_INFO_NO_ARCH (di, gdb_stdout,
				     (fprintf_ftype) fprintf_unfiltered);
      di.flavour = bfd_target_unknown_flavour;
      di.memory_error_func = dis_asm_memory_error;
      di.print_address_func = dis_asm_print_address;
      di_initialized = 1;
    }

  di.mach = tm_print_insn_info.mach;
  if (TARGET_BYTE_ORDER == BIG_ENDIAN)
    tm_print_insn_info.endian = BFD_ENDIAN_BIG;
  else
    tm_print_insn_info.endian = BFD_ENDIAN_LITTLE;

  if (argc != 3 && argc != 4)
    error ("wrong # args");

  if (strcmp (argv[1], "source") == 0)
    mixed_source_and_assembly = 1;
  else if (strcmp (argv[1], "nosource") == 0)
    mixed_source_and_assembly = 0;
  else
    error ("First arg must be 'source' or 'nosource'");

  low = parse_and_eval_address (argv[2]);

  if (argc == 3)
    {
      if (find_pc_partial_function (low, NULL, &low, &high) == 0)
	error ("No function contains specified address");
    }
  else
    high = parse_and_eval_address (argv[3]);

  /* If disassemble_from_exec == -1, then we use the following heuristic to
     determine whether or not to do disassembly from target memory or from the
     exec file:

     If we're debugging a local process, read target memory, instead of the
     exec file.  This makes disassembly of functions in shared libs work
     correctly.

     Else, we're debugging a remote process, and should disassemble from the
     exec file for speed.  However, this is no good if the target modifies its
     code (for relocation, or whatever).
   */

  if (disassemble_from_exec == -1)
    if (strcmp (target_shortname, "child") == 0
	|| strcmp (target_shortname, "procfs") == 0
	|| strcmp (target_shortname, "vxprocess") == 0)
      disassemble_from_exec = 0; /* It's a child process, read inferior mem */
    else
      disassemble_from_exec = 1; /* It's remote, read the exec file */

  if (disassemble_from_exec)
    di.read_memory_func = gdbtk_dis_asm_read_memory;
  else
    di.read_memory_func = dis_asm_read_memory;

  /* If just doing straight assembly, all we need to do is disassemble
     everything between low and high.  If doing mixed source/assembly, we've
     got a totally different path to follow.  */

  if (mixed_source_and_assembly)
    {				/* Come here for mixed source/assembly */
      /* The idea here is to present a source-O-centric view of a function to
	 the user.  This means that things are presented in source order, with
	 (possibly) out of order assembly immediately following.  */
      struct symtab *symtab;
      struct linetable_entry *le;
      int nlines;
      int newlines;
      struct my_line_entry *mle;
      struct symtab_and_line sal;
      int i;
      int out_of_order;
      int next_line;

      symtab = find_pc_symtab (low); /* Assume symtab is valid for whole PC range */

      if (!symtab)
	goto assembly_only;

/* First, convert the linetable to a bunch of my_line_entry's.  */

      le = symtab->linetable->item;
      nlines = symtab->linetable->nitems;

      if (nlines <= 0)
	goto assembly_only;

      mle = (struct my_line_entry *) alloca (nlines * sizeof (struct my_line_entry));

      out_of_order = 0;

/* Copy linetable entries for this function into our data structure, creating
   end_pc's and setting out_of_order as appropriate.  */

/* First, skip all the preceding functions.  */

      for (i = 0; i < nlines - 1 && le[i].pc < low; i++) ;

/* Now, copy all entries before the end of this function.  */

      newlines = 0;
      for (; i < nlines - 1 && le[i].pc < high; i++)
	{
	  if (le[i].line == le[i + 1].line
	      && le[i].pc == le[i + 1].pc)
	    continue;		/* Ignore duplicates */

	  mle[newlines].line = le[i].line;
	  if (le[i].line > le[i + 1].line)
	    out_of_order = 1;
	  mle[newlines].start_pc = le[i].pc;
	  mle[newlines].end_pc = le[i + 1].pc;
	  newlines++;
	}

/* If we're on the last line, and it's part of the function, then we need to
   get the end pc in a special way.  */

      if (i == nlines - 1
	  && le[i].pc < high)
	{
	  mle[newlines].line = le[i].line;
	  mle[newlines].start_pc = le[i].pc;
	  sal = find_pc_line (le[i].pc, 0);
	  mle[newlines].end_pc = sal.end;
	  newlines++;
	}

/* Now, sort mle by line #s (and, then by addresses within lines). */

      if (out_of_order)
	qsort (mle, newlines, sizeof (struct my_line_entry), compare_lines);

/* Now, for each line entry, emit the specified lines (unless they have been
   emitted before), followed by the assembly code for that line.  */

      next_line = 0;		/* Force out first line */
      for (i = 0; i < newlines; i++)
	{
/* Print out everything from next_line to the current line.  */

	  if (mle[i].line >= next_line)
	    {
	      if (next_line != 0)
		print_source_lines (symtab, next_line, mle[i].line + 1, 0);
	      else
		print_source_lines (symtab, mle[i].line, mle[i].line + 1, 0);

	      next_line = mle[i].line + 1;
	    }

	  for (pc = mle[i].start_pc; pc < mle[i].end_pc; )
	    {
	      QUIT;
	      fputs_unfiltered ("    ", gdb_stdout);
	      print_address (pc, gdb_stdout);
	      fputs_unfiltered (":\t    ", gdb_stdout);
	      pc += (*tm_print_insn) (pc, &di);
	      fputs_unfiltered ("\n", gdb_stdout);
	    }
	}
    }
  else
    {
assembly_only:
      for (pc = low; pc < high; )
	{
	  QUIT;
	  fputs_unfiltered ("    ", gdb_stdout);
	  print_address (pc, gdb_stdout);
	  fputs_unfiltered (":\t    ", gdb_stdout);
	  pc += (*tm_print_insn) (pc, &di);
	  fputs_unfiltered ("\n", gdb_stdout);
	}
    }

  gdb_flush (gdb_stdout);

  return TCL_OK;
}
\f
static void
tk_command (cmd, from_tty)
     char *cmd;
     int from_tty;
{
  int retval;
  char *result;
  struct cleanup *old_chain;

  /* Catch case of no argument, since this will make the tcl interpreter dump core. */
  if (cmd == NULL)
    error_no_arg ("tcl command to interpret");

  retval = Tcl_Eval (interp, cmd);

  result = strdup (interp->result);

  old_chain = make_cleanup (free, result);

  if (retval != TCL_OK)
    error (result);

  printf_unfiltered ("%s\n", result);

  do_cleanups (old_chain);
}

static void
cleanup_init (ignored)
     int ignored;
{
  if (interp != NULL)
    Tcl_DeleteInterp (interp);
  interp = NULL;
}

/* Come here during long calculations to check for GUI events.  Usually invoked
   via the QUIT macro.  */

static void
gdbtk_interactive ()
{
  /* Tk_DoOneEvent (TK_DONT_WAIT|TK_IDLE_EVENTS); */
}

/* Come here when there is activity on the X file descriptor. */

static void
x_event (signo)
     int signo;
{
  /* Process pending events */

  while (Tcl_DoOneEvent (TCL_DONT_WAIT|TCL_ALL_EVENTS) != 0);
}

static int
gdbtk_wait (pid, ourstatus)
     int pid;
     struct target_waitstatus *ourstatus;
{
  struct sigaction action;
  static sigset_t nullsigmask = {0};

#ifndef SA_RESTART
  /* Needed for SunOS 4.1.x */
#define SA_RESTART 0
#endif

  action.sa_handler = x_event;
  action.sa_mask = nullsigmask;
  action.sa_flags = SA_RESTART;
#ifndef WINNT
  sigaction(SIGIO, &action, NULL);
#endif

  pid = target_wait (pid, ourstatus);

  action.sa_handler = SIG_IGN;
#ifndef WINNT
  sigaction(SIGIO, &action, NULL); 
#endif

  return pid;
}

/* This is called from execute_command, and provides a wrapper around
   various command routines in a place where both protocol messages and
   user input both flow through.  Mostly this is used for indicating whether
   the target process is running or not.
*/

static void
gdbtk_call_command (cmdblk, arg, from_tty)
     struct cmd_list_element *cmdblk;
     char *arg;
     int from_tty;
{
  running_now = 0;
  if (cmdblk->class == class_run)
    {
      running_now = 1;
      Tcl_Eval (interp, "gdbtk_tcl_busy");
      (*cmdblk->function.cfunc)(arg, from_tty);
      Tcl_Eval (interp, "gdbtk_tcl_idle");
      running_now = 0;
    }
  else
    (*cmdblk->function.cfunc)(arg, from_tty);
}

/* This function is called instead of gdb's internal command loop.  This is the
   last chance to do anything before entering the main Tk event loop. */

static void
tk_command_loop ()
{
  extern GDB_FILE *instream;

  /* We no longer want to use stdin as the command input stream */
  instream = NULL;
  Tcl_Eval (interp, "gdbtk_tcl_preloop");
  Tk_MainLoop ();
}

static void
gdbtk_init ()
{
  struct cleanup *old_chain;
  char *lib, *gdbtk_lib, gdbtk_lib_tmp[1024],gdbtk_file[128];
  int i, found_main;
  struct sigaction action;
  static sigset_t nullsigmask = {0};

  /* If there is no DISPLAY environment variable, Tk_Init below will fail,
     causing gdb to abort.  If instead we simply return here, gdb will
     gracefully degrade to using the command line interface. */

#ifndef WINNT
  if (getenv ("DISPLAY") == NULL)
    return;
#endif

  old_chain = make_cleanup (cleanup_init, 0);

  /* First init tcl and tk. */

  interp = Tcl_CreateInterp ();

  if (!interp)
    error ("Tcl_CreateInterp failed");

  if (Tcl_Init(interp) != TCL_OK)
    error ("Tcl_Init failed: %s", interp->result);

  /*
    if (Itcl_Init(interp) == TCL_ERROR) 
  error ("Itcl_Init failed: %s", interp->result);
    */
  
  if (Tk_Init(interp) != TCL_OK)
    error ("Tk_Init failed: %s", interp->result);

  Tcl_CreateCommand (interp, "gdb_cmd", call_wrapper, gdb_cmd, NULL);
  Tcl_CreateCommand (interp, "gdb_loc", call_wrapper, gdb_loc, NULL);
  Tcl_CreateCommand (interp, "gdb_path_conv", call_wrapper, gdb_path_conv, NULL);
  Tcl_CreateCommand (interp, "gdb_sourcelines", call_wrapper, gdb_sourcelines,
		     NULL);
  Tcl_CreateCommand (interp, "gdb_listfiles", call_wrapper, gdb_listfiles,
		     NULL);
  Tcl_CreateCommand (interp, "gdb_stop", call_wrapper, gdb_stop, NULL);
  Tcl_CreateCommand (interp, "gdb_regnames", call_wrapper, gdb_regnames, NULL);
  Tcl_CreateCommand (interp, "gdb_fetch_registers", call_wrapper,
		     gdb_fetch_registers, NULL);
  Tcl_CreateCommand (interp, "gdb_changed_register_list", call_wrapper,
		     gdb_changed_register_list, NULL);
  Tcl_CreateCommand (interp, "gdb_disassemble", call_wrapper,
		     gdb_disassemble, NULL);
  Tcl_CreateCommand (interp, "gdb_eval", call_wrapper, gdb_eval, NULL);
  Tcl_CreateCommand (interp, "gdb_get_breakpoint_list", call_wrapper,
		     gdb_get_breakpoint_list, NULL);
  Tcl_CreateCommand (interp, "gdb_get_breakpoint_info", call_wrapper,
		     gdb_get_breakpoint_info, NULL);

  command_loop_hook = tk_command_loop;
  print_frame_info_listing_hook =
    (void (*) PARAMS ((struct symtab *, int, int, int))) null_routine;
  query_hook = gdbtk_query;
  flush_hook = gdbtk_flush;
  create_breakpoint_hook = gdbtk_create_breakpoint;
  delete_breakpoint_hook = gdbtk_delete_breakpoint;
  modify_breakpoint_hook = gdbtk_modify_breakpoint;
  interactive_hook = gdbtk_interactive;
  target_wait_hook = gdbtk_wait;
  call_command_hook = gdbtk_call_command;
  readline_begin_hook = gdbtk_readline_begin;
  readline_hook = gdbtk_readline;
  readline_end_hook = gdbtk_readline_end;

  /* Get the file descriptor for the X server */

  x_fd = ConnectionNumber (Tk_Display (Tk_MainWindow (interp)));

  /* Setup for I/O interrupts */

  action.sa_mask = nullsigmask;
  action.sa_flags = 0;
  action.sa_handler = SIG_IGN;
#ifndef WINNT
  sigaction(SIGIO, &action, NULL);
#endif

#ifdef FIOASYNC
  i = 1;
  if (ioctl (x_fd, FIOASYNC, &i))
    perror_with_name ("gdbtk_init: ioctl FIOASYNC failed");

#ifdef SIOCSPGRP
  i = getpid();
  if (ioctl (x_fd, SIOCSPGRP, &i))
    perror_with_name ("gdbtk_init: ioctl SIOCSPGRP failed");

#else
#ifdef F_SETOWN
  i = getpid();
  if (fcntl (x_fd, F_SETOWN, i))
    perror_with_name ("gdbtk_init: fcntl F_SETOWN failed");
#endif	/* F_SETOWN */
#endif	/* !SIOCSPGRP */
#else
#ifndef WINNT
  if (ioctl (x_fd,  I_SETSIG, S_INPUT|S_RDNORM) < 0)
    perror_with_name ("gdbtk_init: ioctl I_SETSIG failed");
#endif

#endif /* ifndef FIOASYNC */

  add_com ("tk", class_obscure, tk_command,
	   "Send a command directly into tk.");

  Tcl_LinkVar (interp, "disassemble-from-exec", (char *)&disassemble_from_exec,
	       TCL_LINK_INT);

  /* find the gdb tcl library and source main.tcl */

  gdbtk_lib = getenv ("GDBTK_LIBRARY");
  if (!gdbtk_lib)
    if (access ("gdbtcl/main.tcl", R_OK) == 0)
      gdbtk_lib = "gdbtcl";
    else
      gdbtk_lib = GDBTK_LIBRARY;

  strcpy (gdbtk_lib_tmp, gdbtk_lib);
  found_main = 0;
  /* see if GDBTK_LIBRARY is a path list */
  lib = strtok (gdbtk_lib_tmp, GDBTK_PATH_SEP);
  do
    {
      if (Tcl_VarEval (interp, "lappend auto_path ", lib, NULL) != TCL_OK)
	{
	  fputs_unfiltered (Tcl_GetVar (interp, "errorInfo", 0), gdb_stderr);
	  error ("");
	}
      if (!found_main)
	{
	  strcpy (gdbtk_file, lib);
	  strcat (gdbtk_file, "/main.tcl");
	  if (access (gdbtk_file, R_OK) == 0)
	    {
	      found_main++;
	      Tcl_SetVar (interp, "GDBTK_LIBRARY", lib, 0);
	    }
	}
     } 
  while (lib = strtok (NULL, ":"));
  
  if (!found_main)
    {
      fputs_unfiltered_hook = NULL; /* Force errors to stdout/stderr */
      if (getenv("GDBTK_LIBRARY"))
	{
	  fprintf_unfiltered (stderr, "Unable to find main.tcl in %s\n",getenv("GDBTK_LIBRARY"));
	  fprintf_unfiltered (stderr, 
			      "Please set GDBTK_LIBRARY to a path that includes the GDB tcl files.\n");
	}
      else
	{
	  fprintf_unfiltered (stderr, "Unable to find main.tcl in %s\n", GDBTK_LIBRARY);
	  fprintf_unfiltered (stderr, "You might want to set GDBTK_LIBRARY\n");	  
	}
      error("");
    }

/* Defer setup of fputs_unfiltered_hook to near the end so that error messages
   prior to this point go to stdout/stderr.  */

  fputs_unfiltered_hook = gdbtk_fputs;

  if (Tcl_EvalFile (interp, gdbtk_file) != TCL_OK)
    {
      fputs_unfiltered_hook = NULL; /* Force errors to stdout/stderr */

      fprintf_unfiltered (stderr, "%s:%d: %s\n", gdbtk_file,
			  interp->errorLine, interp->result);

      fputs_unfiltered ("Stack trace:\n", gdb_stderr);
      fputs_unfiltered (Tcl_GetVar (interp, "errorInfo", 0), gdb_stderr);
      error ("");
    }

  discard_cleanups (old_chain);
}

/* Come here during initialize_all_files () */

void
_initialize_gdbtk ()
{
  if (use_windows)
    {
      /* Tell the rest of the world that Gdbtk is now set up. */

      init_ui_hook = gdbtk_init;
    }
}

[-- Attachment #3: infcmd.c --]
[-- Type: text/x-c, Size: 39758 bytes --]

/* Memory-access and commands for "inferior" process, for GDB.
   Copyright 1986, 1987, 1988, 1989, 1991, 1992, 1995, 1996 Free Software Foundation, Inc.

This file is part of GDB.

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */

#include "defs.h"
#include <signal.h>
#include "gdb_string.h"
#include "symtab.h"
#include "gdbtypes.h"
#include "frame.h"
#include "inferior.h"
#include "environ.h"
#include "value.h"
#include "gdbcmd.h"
#include "gdbcore.h"
#include "target.h"
#include "language.h"
#include "symfile.h"

static void continue_command PARAMS ((char *, int));

static void until_next_command PARAMS ((int));

static void until_command PARAMS ((char *, int));

static void path_info PARAMS ((char *, int));

static void path_command PARAMS ((char *, int));

static void unset_command PARAMS ((char *, int));

static void float_info PARAMS ((char *, int));

static void detach_command PARAMS ((char *, int));

static void nofp_registers_info PARAMS ((char *, int));

static void all_registers_info PARAMS ((char *, int));

static void registers_info PARAMS ((char *, int));

#if !defined (DO_REGISTERS_INFO)
static void do_registers_info PARAMS ((int, int));
#endif

static void unset_environment_command PARAMS ((char *, int));

static void set_environment_command PARAMS ((char *, int));

static void environment_info PARAMS ((char *, int));

static void program_info PARAMS ((char *, int));

static void finish_command PARAMS ((char *, int));

static void signal_command PARAMS ((char *, int));

static void jump_command PARAMS ((char *, int));

static void step_1 PARAMS ((int, int, char *));

static void nexti_command PARAMS ((char *, int));

static void stepi_command PARAMS ((char *, int));

static void next_command PARAMS ((char *, int));

static void step_command PARAMS ((char *, int));

static void run_command PARAMS ((char *, int));

#ifdef CALL_DUMMY_BREAKPOINT_OFFSET
static void breakpoint_auto_delete_contents PARAMS ((PTR));
#endif

#define ERROR_NO_INFERIOR \
   if (!target_has_execution) error ("The program is not being run.");

/* String containing arguments to give to the program, separated by spaces.
   Empty string (pointer to '\0') means no args.  */

static char *inferior_args;

/* File name for default use for standard in/out in the inferior.  */

char *inferior_io_terminal;

/* Pid of our debugged inferior, or 0 if no inferior now.
   Since various parts of infrun.c test this to see whether there is a program
   being debugged it should be nonzero (currently 3 is used) for remote
   debugging.  */

int inferior_pid;

/* Last signal that the inferior received (why it stopped).  */

enum target_signal stop_signal;

/* Address at which inferior stopped.  */

CORE_ADDR stop_pc;

/* Chain containing status of breakpoint(s) that we have stopped at.  */

bpstat stop_bpstat;

/* Flag indicating that a command has proceeded the inferior past the
   current breakpoint.  */

int breakpoint_proceeded;

/* Nonzero if stopped due to a step command.  */

int stop_step;

/* Nonzero if stopped due to completion of a stack dummy routine.  */

int stop_stack_dummy;

/* Nonzero if stopped due to a random (unexpected) signal in inferior
   process.  */

int stopped_by_random_signal;

/* Range to single step within.
   If this is nonzero, respond to a single-step signal
   by continuing to step if the pc is in this range.  */

CORE_ADDR step_range_start; /* Inclusive */
CORE_ADDR step_range_end; /* Exclusive */

/* Stack frame address as of when stepping command was issued.
   This is how we know when we step into a subroutine call,
   and how to set the frame for the breakpoint used to step out.  */

CORE_ADDR step_frame_address;

/* Our notion of the current stack pointer.  */

CORE_ADDR step_sp;

/* 1 means step over all subroutine calls.
   0 means don't step over calls (used by stepi).
   -1 means step over calls to undebuggable functions.  */

int step_over_calls;

/* If stepping, nonzero means step count is > 1
   so don't print frame next time inferior stops
   if it stops due to stepping.  */

int step_multi;

/* Environment to use for running inferior,
   in format described in environ.h.  */

struct environ *inferior_environ;

\f
/* ARGSUSED */
void
tty_command (file, from_tty)
     char *file;
     int from_tty;
{
  if (file == 0)
    error_no_arg ("terminal name for running target process");

  inferior_io_terminal = savestring (file, strlen (file));
}

static void
run_command (args, from_tty)
     char *args;
     int from_tty;
{
  char *exec_file;

  dont_repeat ();

  if (inferior_pid != 0 && target_has_execution)
    {
      if (
	  !query ("The program being debugged has been started already.\n\
Start it from the beginning? "))
	error ("Program not restarted.");
      target_kill ();
    }

  clear_breakpoint_hit_counts ();

  exec_file = (char *) get_exec_file (0);

  /* The exec file is re-read every time we do a generic_mourn_inferior, so
     we just have to worry about the symbol file.  */
  reread_symbols ();

  /* We keep symbols from add-symbol-file, on the grounds that the
     user might want to add some symbols before running the program
     (right?).  But sometimes (dynamic loading where the user manually
     introduces the new symbols with add-symbol-file), the code which
     the symbols describe does not persist between runs.  Currently
     the user has to manually nuke all symbols between runs if they
     want them to go away (PR 2207).  This is probably reasonable.  */

  if (args)
    {
      char *cmd;
      cmd = concat ("set args ", args, NULL);
      make_cleanup (free, cmd);
      execute_command (cmd, from_tty);
    }

  if (from_tty)
    {
      puts_filtered("Starting program: ");
      if (exec_file)
	puts_filtered(exec_file);
      puts_filtered(" ");
      puts_filtered(inferior_args);
      puts_filtered("\n");
      gdb_flush (gdb_stdout);
    }

  target_create_inferior (exec_file, inferior_args,
			  environ_vector (inferior_environ));
}
\f
static void
continue_command (proc_count_exp, from_tty)
     char *proc_count_exp;
     int from_tty;
{
  ERROR_NO_INFERIOR;

  /* If have argument, set proceed count of breakpoint we stopped at.  */

  if (proc_count_exp != NULL)
    {
      bpstat bs = stop_bpstat;
      int num = bpstat_num (&bs);
      if (num == 0 && from_tty)
	{
	  printf_filtered
	    ("Not stopped at any breakpoint; argument ignored.\n");
	}
      while (num != 0)
	{
	  set_ignore_count (num,
			    parse_and_eval_address (proc_count_exp) - 1,
			    from_tty);
	  /* set_ignore_count prints a message ending with a period.
	     So print two spaces before "Continuing.".  */
	  if (from_tty)
	    printf_filtered ("  ");
	  num = bpstat_num (&bs);
	}
    }

  if (from_tty)
    printf_filtered ("Continuing.\n");

  clear_proceed_status ();

  proceed ((CORE_ADDR) -1, TARGET_SIGNAL_DEFAULT, 0);
}
\f
/* Step until outside of current statement.  */

/* ARGSUSED */
static void
step_command (count_string, from_tty)
     char *count_string;
     int from_tty;
{
  step_1 (0, 0, count_string);
}

/* Likewise, but skip over subroutine calls as if single instructions.  */

/* ARGSUSED */
static void
next_command (count_string, from_tty)
     char *count_string;
     int from_tty;
{
  step_1 (1, 0, count_string);
}

/* Likewise, but step only one instruction.  */

/* ARGSUSED */
static void
stepi_command (count_string, from_tty)
     char *count_string;
     int from_tty;
{
  step_1 (0, 1, count_string);
}

/* ARGSUSED */
static void
nexti_command (count_string, from_tty)
     char *count_string;
     int from_tty;
{
  step_1 (1, 1, count_string);
}

static void
step_1 (skip_subroutines, single_inst, count_string)
     int skip_subroutines;
     int single_inst;
     char *count_string;
{
  register int count = 1;
  struct frame_info *frame;
  struct cleanup *cleanups = 0;

  ERROR_NO_INFERIOR;
  count = count_string ? parse_and_eval_address (count_string) : 1;

  if (!single_inst || skip_subroutines) /* leave si command alone */
    {
      enable_longjmp_breakpoint();
      cleanups = make_cleanup(disable_longjmp_breakpoint, 0);
    }

  for (; count > 0; count--)
    {
      clear_proceed_status ();

      frame = get_current_frame ();
      if (!frame)			/* Avoid coredump here.  Why tho? */
	error ("No current frame");
      step_frame_address = FRAME_FP (frame);
      step_sp = read_sp ();

      if (! single_inst)
	{
	  find_pc_line_pc_range (stop_pc, &step_range_start, &step_range_end);
	  if (step_range_end == 0)
	    {
	      char *name;
	      if (find_pc_partial_function (stop_pc, &name, &step_range_start,
					    &step_range_end) == 0)
		error ("Cannot find bounds of current function");

	      target_terminal_ours ();
	      printf_filtered ("\
Single stepping until exit from function %s, \n\
which has no line number information.\n", name);
	    }
	}
      else
	{
	  /* Say we are stepping, but stop after one insn whatever it does.  */
	  step_range_start = step_range_end = 1;
	  if (!skip_subroutines)
	    /* It is stepi.
	       Don't step over function calls, not even to functions lacking
	       line numbers.  */
	    step_over_calls = 0;
	}

      if (skip_subroutines)
	step_over_calls = 1;

      step_multi = (count > 1);
      proceed ((CORE_ADDR) -1, TARGET_SIGNAL_DEFAULT, 1);
      if (! stop_step)
	break;

      /* FIXME: On nexti, this may have already been done (when we hit the
	 step resume break, I think).  Probably this should be moved to
	 wait_for_inferior (near the top).  */
#if defined (SHIFT_INST_REGS)
      SHIFT_INST_REGS();
#endif
    }

  if (!single_inst || skip_subroutines)
    do_cleanups(cleanups);
}
\f
/* Continue program at specified address.  */

static void
jump_command (arg, from_tty)
     char *arg;
     int from_tty;
{
  register CORE_ADDR addr;
  struct symtabs_and_lines sals;
  struct symtab_and_line sal;
  struct symbol *fn;
  struct symbol *sfn;

  ERROR_NO_INFERIOR;

  if (!arg)
    error_no_arg ("starting address");

  sals = decode_line_spec_1 (arg, 1);
  if (sals.nelts != 1)
    {
      error ("Unreasonable jump request");
    }

  sal = sals.sals[0];
  free ((PTR)sals.sals);

  if (sal.symtab == 0 && sal.pc == 0)
    error ("No source file has been specified.");

  resolve_sal_pc (&sal);			/* May error out */

  /* See if we are trying to jump to another function. */
  fn = get_frame_function (get_current_frame ());
  sfn = find_pc_function (sal.pc);
  if (fn != NULL && sfn != fn)
    {
      if (!query ("Line %d is not in `%s'.  Jump anyway? ", sal.line,
		  SYMBOL_SOURCE_NAME (fn)))
	{
	  error ("Not confirmed.");
	  /* NOTREACHED */
	}
    }
  fixup_symbol_section (sfn, 0);
  if (sfn!=NULL &&
      section_is_overlay (SYMBOL_BFD_SECTION (sfn)) && 
      !section_is_mapped (SYMBOL_BFD_SECTION (sfn)))
    {
      if (!query ("WARNING!!!  Destination is in unmapped overlay!  Jump anyway? "))
	{
	  error ("Not confirmed.");
	  /* NOTREACHED */
	}
    }


  addr = sal.pc;

  if (from_tty)
    {
      printf_filtered ("Continuing at ");
      print_address_numeric (addr, 1, gdb_stdout);
      printf_filtered (".\n");
    }

  clear_proceed_status ();
  proceed (addr, TARGET_SIGNAL_0, 0);
}

/* Continue program giving it specified signal.  */

static void
signal_command (signum_exp, from_tty)
     char *signum_exp;
     int from_tty;
{
  enum target_signal oursig;

  dont_repeat ();		/* Too dangerous.  */
  ERROR_NO_INFERIOR;

  if (!signum_exp)
    error_no_arg ("signal number");

  /* It would be even slicker to make signal names be valid expressions,
     (the type could be "enum $signal" or some such), then the user could
     assign them to convenience variables.  */
  oursig = target_signal_from_name (signum_exp);

  if (oursig == TARGET_SIGNAL_UNKNOWN)
    {
      /* No, try numeric.  */
      int num = parse_and_eval_address (signum_exp);

      if (num == 0)
	oursig = TARGET_SIGNAL_0;
      else
	oursig = target_signal_from_command (num);
    }

  if (from_tty)
    {
      if (oursig == TARGET_SIGNAL_0)
	printf_filtered ("Continuing with no signal.\n");
      else
	printf_filtered ("Continuing with signal %s.\n",
			 target_signal_to_name (oursig));
    }

  clear_proceed_status ();
  /* "signal 0" should not get stuck if we are stopped at a breakpoint.
     FIXME: Neither should "signal foo" but when I tried passing
     (CORE_ADDR)-1 unconditionally I got a testsuite failure which I haven't
     tried to track down yet.  */
  proceed (oursig == TARGET_SIGNAL_0 ? (CORE_ADDR) -1 : stop_pc, oursig, 0);
}

/* Call breakpoint_auto_delete on the current contents of the bpstat
   pointed to by arg (which is really a bpstat *).  */

#ifdef CALL_DUMMY_BREAKPOINT_OFFSET

static void
breakpoint_auto_delete_contents (arg)
     PTR arg;
{
  breakpoint_auto_delete (*(bpstat *)arg);
}

#endif	/* CALL_DUMMY_BREAKPOINT_OFFSET */

/* Execute a "stack dummy", a piece of code stored in the stack
   by the debugger to be executed in the inferior.

   To call: first, do PUSH_DUMMY_FRAME.
   Then push the contents of the dummy.  It should end with a breakpoint insn.
   Then call here, passing address at which to start the dummy.

   The contents of all registers are saved before the dummy frame is popped
   and copied into the buffer BUFFER.

   The dummy's frame is automatically popped whenever that break is hit.
   If that is the first time the program stops, run_stack_dummy
   returns to its caller with that frame already gone and returns 0.
   Otherwise, run_stack-dummy returns 1 (the frame will eventually be popped
   when we do hit that breakpoint).  */

/* DEBUG HOOK:  4 => return instead of letting the stack dummy run.  */

static int stack_dummy_testing = 0;

int
run_stack_dummy (addr, buffer)
     CORE_ADDR addr;
     char buffer[REGISTER_BYTES];
{
  struct cleanup *old_cleanups = make_cleanup (null_cleanup, 0);

  /* Now proceed, having reached the desired place.  */
  clear_proceed_status ();
  if (stack_dummy_testing & 4)
    {
      POP_FRAME;
      return(0);
    }
#ifdef CALL_DUMMY_BREAKPOINT_OFFSET
  {
    struct breakpoint *bpt;
    struct symtab_and_line sal;

    INIT_SAL (&sal);	/* initialize to zeroes */
#if CALL_DUMMY_LOCATION != AT_ENTRY_POINT
    sal.pc = addr - CALL_DUMMY_START_OFFSET + CALL_DUMMY_BREAKPOINT_OFFSET;
#else
    sal.pc = CALL_DUMMY_ADDRESS ();
#endif
    sal.section = find_pc_overlay (sal.pc);

    /* Set up a FRAME for the dummy frame so we can pass it to
       set_momentary_breakpoint.  We need to give the breakpoint a
       frame in case there is only one copy of the dummy (e.g.
       CALL_DUMMY_LOCATION == AFTER_TEXT_END).  */
    flush_cached_frames ();
    set_current_frame (create_new_frame (read_fp (), sal.pc));

    /* If defined, CALL_DUMMY_BREAKPOINT_OFFSET is where we need to put
       a breakpoint instruction.  If not, the call dummy already has the
       breakpoint instruction in it.

       addr is the address of the call dummy plus the CALL_DUMMY_START_OFFSET,
       so we need to subtract the CALL_DUMMY_START_OFFSET.  */
    bpt = set_momentary_breakpoint (sal,
				    get_current_frame (),
				    bp_call_dummy);
    bpt->disposition = del;

    /* If all error()s out of proceed ended up calling normal_stop (and
       perhaps they should; it already does in the special case of error
       out of resume()), then we wouldn't need this.  */
    make_cleanup (breakpoint_auto_delete_contents, &stop_bpstat);
  }
#endif /* CALL_DUMMY_BREAKPOINT_OFFSET.  */

  proceed_to_finish = 1;	/* We want stop_registers, please... */
  proceed (addr, TARGET_SIGNAL_0, 0);

  discard_cleanups (old_cleanups);

  if (!stop_stack_dummy)
    return 1;

  /* On return, the stack dummy has been popped already.  */

  memcpy (buffer, stop_registers, sizeof stop_registers);
  return 0;
}
\f
/* Proceed until we reach a different source line with pc greater than
   our current one or exit the function.  We skip calls in both cases.

   Note that eventually this command should probably be changed so
   that only source lines are printed out when we hit the breakpoint
   we set.  This may involve changes to wait_for_inferior and the
   proceed status code.  */

/* ARGSUSED */
static void
until_next_command (from_tty)
     int from_tty;
{
  struct frame_info *frame;
  CORE_ADDR pc;
  struct symbol *func;
  struct symtab_and_line sal;
 
  clear_proceed_status ();

  frame = get_current_frame ();

  /* Step until either exited from this function or greater
     than the current line (if in symbolic section) or pc (if
     not). */

  pc = read_pc ();
  func = find_pc_function (pc);
  
  if (!func)
    {
      struct minimal_symbol *msymbol = lookup_minimal_symbol_by_pc (pc);
      
      if (msymbol == NULL)
	error ("Execution is not within a known function.");
      
      step_range_start = SYMBOL_VALUE_ADDRESS (msymbol);
      step_range_end = pc;
    }
  else
    {
      sal = find_pc_line (pc, 0);
      
      step_range_start = BLOCK_START (SYMBOL_BLOCK_VALUE (func));
      step_range_end = sal.end;
    }
  
  step_over_calls = 1;
  step_frame_address = FRAME_FP (frame);
  step_sp = read_sp ();

  step_multi = 0;		/* Only one call to proceed */
  
  proceed ((CORE_ADDR) -1, TARGET_SIGNAL_DEFAULT, 1);
}

static void 
until_command (arg, from_tty)
     char *arg;
     int from_tty;
{
  if (!target_has_execution)
    error ("The program is not running.");
  if (arg)
    until_break_command (arg, from_tty);
  else
    until_next_command (from_tty);
}
\f
/* "finish": Set a temporary breakpoint at the place
   the selected frame will return to, then continue.  */

static void
finish_command (arg, from_tty)
     char *arg;
     int from_tty;
{
  struct symtab_and_line sal;
  register struct frame_info *frame;
  register struct symbol *function;
  struct breakpoint *breakpoint;
  struct cleanup *old_chain;

  if (arg)
    error ("The \"finish\" command does not take any arguments.");
  if (!target_has_execution)
    error ("The program is not running.");
  if (selected_frame == NULL)
    error ("No selected frame.");

  frame = get_prev_frame (selected_frame);
  if (frame == 0)
    error ("\"finish\" not meaningful in the outermost frame.");

  clear_proceed_status ();

  sal = find_pc_line (frame->pc, 0);
  sal.pc = frame->pc;

  breakpoint = set_momentary_breakpoint (sal, frame, bp_finish);

  old_chain = make_cleanup(delete_breakpoint, breakpoint);

  /* Find the function we will return from.  */

  function = find_pc_function (selected_frame->pc);

  /* Print info on the selected frame, including level number
     but not source.  */
  if (from_tty)
    {
      printf_filtered ("Run till exit from ");
      print_stack_frame (selected_frame, selected_frame_level, 0);
    }

  proceed_to_finish = 1;		/* We want stop_registers, please... */
  proceed ((CORE_ADDR) -1, TARGET_SIGNAL_DEFAULT, 0);

  /* Did we stop at our breakpoint? */
  if (bpstat_find_breakpoint(stop_bpstat, breakpoint) != NULL
      && function != 0)
    {
      struct type *value_type;
      register value_ptr val;
      CORE_ADDR funcaddr;

      value_type = TYPE_TARGET_TYPE (SYMBOL_TYPE (function));
      if (!value_type)
	fatal ("internal: finish_command: function has no target type");
      
      if (TYPE_CODE (value_type) == TYPE_CODE_VOID)
	return;

      funcaddr = BLOCK_START (SYMBOL_BLOCK_VALUE (function));

      val = value_being_returned (value_type, stop_registers,
	      using_struct_return (value_of_variable (function, NULL),
				   funcaddr,
				   check_typedef (value_type),
		BLOCK_GCC_COMPILED (SYMBOL_BLOCK_VALUE (function))));

      printf_filtered ("Value returned is $%d = ", record_latest_value (val));
      value_print (val, gdb_stdout, 0, Val_no_prettyprint);
      printf_filtered ("\n");
    }
  do_cleanups(old_chain);
}
\f
/* ARGSUSED */
static void
program_info (args, from_tty)
    char *args;
    int from_tty;
{
  bpstat bs = stop_bpstat;
  int num = bpstat_num (&bs);
  
  if (!target_has_execution)
    {
      printf_filtered ("The program being debugged is not being run.\n");
      return;
    }

  target_files_info ();
  printf_filtered ("Program stopped at %s.\n",
		   local_hex_string((unsigned long) stop_pc));
  if (stop_step)
    printf_filtered ("It stopped after being stepped.\n");
  else if (num != 0)
    {
      /* There may be several breakpoints in the same place, so this
	 isn't as strange as it seems.  */
      while (num != 0)
	{
	  if (num < 0)
	    printf_filtered ("It stopped at a breakpoint that has since been deleted.\n");
	  else
	    printf_filtered ("It stopped at breakpoint %d.\n", num);
	  num = bpstat_num (&bs);
	}
    }
  else if (stop_signal != TARGET_SIGNAL_0)
    {
      printf_filtered ("It stopped with signal %s, %s.\n",
		       target_signal_to_name (stop_signal),
		       target_signal_to_string (stop_signal));
    }

  if (!from_tty)
    printf_filtered ("Type \"info stack\" or \"info registers\" for more information.\n");
}
\f
static void
environment_info (var, from_tty)
     char *var;
     int from_tty;
{
  if (var)
    {
      register char *val = get_in_environ (inferior_environ, var);
      if (val)
	{
	  puts_filtered (var);
	  puts_filtered (" = ");
	  puts_filtered (val);
	  puts_filtered ("\n");
	}
      else
	{
	  puts_filtered ("Environment variable \"");
	  puts_filtered (var);
	  puts_filtered ("\" not defined.\n");
	}
    }
  else
    {
      register char **vector = environ_vector (inferior_environ);
      while (*vector)
	{
	  puts_filtered (*vector++);
	  puts_filtered ("\n");
	}
    }
}

static void
set_environment_command (arg, from_tty)
     char *arg;
     int from_tty;
{
  register char *p, *val, *var;
  int nullset = 0;

  if (arg == 0)
    error_no_arg ("environment variable and value");

  /* Find seperation between variable name and value */
  p = (char *) strchr (arg, '=');
  val = (char *) strchr (arg, ' ');

  if (p != 0 && val != 0)
    {
      /* We have both a space and an equals.  If the space is before the
	 equals, walk forward over the spaces til we see a nonspace 
	 (possibly the equals). */
      if (p > val)
	while (*val == ' ')
	  val++;

      /* Now if the = is after the char following the spaces,
	 take the char following the spaces.  */
      if (p > val)
	p = val - 1;
    }
  else if (val != 0 && p == 0)
    p = val;

  if (p == arg)
    error_no_arg ("environment variable to set");

  if (p == 0 || p[1] == 0)
    {
      nullset = 1;
      if (p == 0)
	p = arg + strlen (arg);	/* So that savestring below will work */
    }
  else
    {
      /* Not setting variable value to null */
      val = p + 1;
      while (*val == ' ' || *val == '\t')
	val++;
    }

  while (p != arg && (p[-1] == ' ' || p[-1] == '\t')) p--;

  var = savestring (arg, p - arg);
  if (nullset)
    {
      printf_filtered ("Setting environment variable \"%s\" to null value.\n", var);
      set_in_environ (inferior_environ, var, "");
    }
  else
    set_in_environ (inferior_environ, var, val);
  free (var);
}

static void
unset_environment_command (var, from_tty)
     char *var;
     int from_tty;
{
  if (var == 0)
    {
      /* If there is no argument, delete all environment variables.
	 Ask for confirmation if reading from the terminal.  */
      if (!from_tty || query ("Delete all environment variables? "))
	{
	  free_environ (inferior_environ);
	  inferior_environ = make_environ ();
	}
    }
  else
    unset_in_environ (inferior_environ, var);
}

/* Handle the execution path (PATH variable) */

static const char path_var_name[] = "PATH";

/* ARGSUSED */
static void
path_info (args, from_tty)
     char *args;
     int from_tty;
{
  puts_filtered ("Executable and object file path: ");
  puts_filtered (get_in_environ (inferior_environ, path_var_name));
  puts_filtered ("\n");
}

/* Add zero or more directories to the front of the execution path.  */

static void
path_command (dirname, from_tty)
     char *dirname;
     int from_tty;
{
  char *exec_path;
  char *env;
  dont_repeat ();
  env = get_in_environ (inferior_environ, path_var_name);
  /* Can be null if path is not set */
  if (!env)
    env = "";
  exec_path = strsave (env);
  mod_path (dirname, &exec_path);
  set_in_environ (inferior_environ, path_var_name, exec_path);
  free (exec_path);
  if (from_tty)
    path_info ((char *)NULL, from_tty);
}
\f
/* The array of register names.  */

char *reg_names[] = REGISTER_NAMES;

/* Print out the machine register regnum. If regnum is -1,
   print all registers (fpregs == 1) or all non-float registers
   (fpregs == 0).

   For most machines, having all_registers_info() print the
   register(s) one per line is good enough. If a different format
   is required, (eg, for MIPS or Pyramid 90x, which both have
   lots of regs), or there is an existing convention for showing
   all the registers, define the macro DO_REGISTERS_INFO(regnum, fp)
   to provide that format.  */  

#if !defined (DO_REGISTERS_INFO)

#define DO_REGISTERS_INFO(regnum, fp) do_registers_info(regnum, fp)

static void
do_registers_info (regnum, fpregs)
     int regnum;
     int fpregs;
{
  register int i;
  int numregs = ARCH_NUM_REGS;

  for (i = 0; i < numregs; i++)
    {
      char raw_buffer[MAX_REGISTER_RAW_SIZE];
      char virtual_buffer[MAX_REGISTER_VIRTUAL_SIZE];

      /* Decide between printing all regs, nonfloat regs, or specific reg.  */
      if (regnum == -1) {
	if (TYPE_CODE (REGISTER_VIRTUAL_TYPE (i)) == TYPE_CODE_FLT && !fpregs)
	  continue;
      } else {
        if (i != regnum)
	  continue;
      }

      /* If the register name is empty, it is undefined for this
	 processor, so don't display anything.  */
      if (reg_names[i] == NULL || *(reg_names[i]) == '\0')
	continue;

      fputs_filtered (reg_names[i], gdb_stdout);
      print_spaces_filtered (15 - strlen (reg_names[i]), gdb_stdout);

      /* Get the data in raw format.  */
      if (read_relative_register_raw_bytes (i, raw_buffer))
	{
	  printf_filtered ("Invalid register contents\n");
	  continue;
	}

      /* Convert raw data to virtual format if necessary.  */
#ifdef REGISTER_CONVERTIBLE
      if (REGISTER_CONVERTIBLE (i))
	{
	  REGISTER_CONVERT_TO_VIRTUAL (i, REGISTER_VIRTUAL_TYPE (i),
				       raw_buffer, virtual_buffer);
	}
      else
#endif
	memcpy (virtual_buffer, raw_buffer,
		REGISTER_VIRTUAL_SIZE (i));

      /* If virtual format is floating, print it that way, and in raw hex.  */
      if (TYPE_CODE (REGISTER_VIRTUAL_TYPE (i)) == TYPE_CODE_FLT)
	{
	  register int j;

#ifdef INVALID_FLOAT
	  if (INVALID_FLOAT (virtual_buffer, REGISTER_VIRTUAL_SIZE (i)))
	    printf_filtered ("<invalid float>");
	  else
#endif
	    val_print (REGISTER_VIRTUAL_TYPE (i), virtual_buffer, 0,
		       gdb_stdout, 0, 1, 0, Val_pretty_default);

	  printf_filtered ("\t(raw 0x");
	  for (j = 0; j < REGISTER_RAW_SIZE (i); j++)
	    {
	      register int idx = TARGET_BYTE_ORDER == BIG_ENDIAN ? j
		: REGISTER_RAW_SIZE (i) - 1 - j;
	      printf_filtered ("%02x", (unsigned char)raw_buffer[idx]);
	    }
	  printf_filtered (")");
	}

/* FIXME!  val_print probably can handle all of these cases now...  */

      /* Else if virtual format is too long for printf,
	 print in hex a byte at a time.  */
      else if (REGISTER_VIRTUAL_SIZE (i) > (int) sizeof (long))
	{
	  register int j;
	  printf_filtered ("0x");
	  for (j = 0; j < REGISTER_VIRTUAL_SIZE (i); j++)
	    printf_filtered ("%02x", (unsigned char)virtual_buffer[j]);
	}
      /* Else print as integer in hex and in decimal.  */
      else
	{
	  val_print (REGISTER_VIRTUAL_TYPE (i), virtual_buffer, 0,
		     gdb_stdout, 'x', 1, 0, Val_pretty_default);
	  printf_filtered ("\t");
	  val_print (REGISTER_VIRTUAL_TYPE (i), virtual_buffer, 0,
		     gdb_stdout,   0, 1, 0, Val_pretty_default);
	}

      /* The SPARC wants to print even-numbered float regs as doubles
	 in addition to printing them as floats.  */
#ifdef PRINT_REGISTER_HOOK
      PRINT_REGISTER_HOOK (i);
#endif

      printf_filtered ("\n");
    }
}
#endif /* no DO_REGISTERS_INFO.  */

static void
registers_info (addr_exp, fpregs)
     char *addr_exp;
     int fpregs;
{
  int regnum, numregs;
  register char *end;

  if (!target_has_registers)
    error ("The program has no registers now.");
  if (selected_frame == NULL)
    error ("No selected frame.");

  if (!addr_exp)
    {
      DO_REGISTERS_INFO(-1, fpregs);
      return;
    }

  do
    {      
      if (addr_exp[0] == '$')
	addr_exp++;
      end = addr_exp;
      while (*end != '\0' && *end != ' ' && *end != '\t')
	++end;
      numregs = ARCH_NUM_REGS;
      for (regnum = 0; regnum < numregs; regnum++)
	if (!strncmp (addr_exp, reg_names[regnum], end - addr_exp)
	    && strlen (reg_names[regnum]) == end - addr_exp)
	  goto found;
      if (*addr_exp >= '0' && *addr_exp <= '9')
	regnum = atoi (addr_exp);		/* Take a number */
      if (regnum >= numregs)		/* Bad name, or bad number */
	error ("%.*s: invalid register", end - addr_exp, addr_exp);

found:
      DO_REGISTERS_INFO(regnum, fpregs);

      addr_exp = end;
      while (*addr_exp == ' ' || *addr_exp == '\t')
	++addr_exp;
    } while (*addr_exp != '\0');
}

static void
all_registers_info (addr_exp, from_tty)
     char *addr_exp;
     int from_tty;
{
  registers_info (addr_exp, 1);
}

static void
nofp_registers_info (addr_exp, from_tty)
     char *addr_exp;
     int from_tty;
{
  registers_info (addr_exp, 0);
}
\f
/*
 * TODO:
 * Should save/restore the tty state since it might be that the
 * program to be debugged was started on this tty and it wants
 * the tty in some state other than what we want.  If it's running
 * on another terminal or without a terminal, then saving and
 * restoring the tty state is a harmless no-op.
 * This only needs to be done if we are attaching to a process.
 */

/*
   attach_command --
   takes a program started up outside of gdb and ``attaches'' to it.
   This stops it cold in its tracks and allows us to start debugging it.
   and wait for the trace-trap that results from attaching.  */

void
attach_command (args, from_tty)
     char *args;
     int from_tty;
{
#ifdef SOLIB_ADD
  extern int auto_solib_add;
#endif

  dont_repeat ();			/* Not for the faint of heart */

  if (target_has_execution)
    {
      if (query ("A program is being debugged already.  Kill it? "))
	target_kill ();
      else
	error ("Not killed.");
    }

  target_attach (args, from_tty);

  /* Set up the "saved terminal modes" of the inferior
     based on what modes we are starting it with.  */
  target_terminal_init ();

  /* Install inferior's terminal modes.  */
  target_terminal_inferior ();

  /* Set up execution context to know that we should return from
     wait_for_inferior as soon as the target reports a stop.  */
  init_wait_for_inferior ();
  clear_proceed_status ();
  stop_soon_quietly = 1;

  /* No traps are generated when attaching to inferior under Mach 3
     or GNU hurd.  */
#ifndef ATTACH_NO_WAIT
  wait_for_inferior ();
#endif

#ifdef SOLIB_ADD
  if (auto_solib_add)
    {
      /* Add shared library symbols from the newly attached process, if any.  */
      SOLIB_ADD ((char *)0, from_tty, (struct target_ops *)0);
      re_enable_breakpoints_in_shlibs ();
    }
#endif

  normal_stop ();
}

/*
 * detach_command --
 * takes a program previously attached to and detaches it.
 * The program resumes execution and will no longer stop
 * on signals, etc.  We better not have left any breakpoints
 * in the program or it'll die when it hits one.  For this
 * to work, it may be necessary for the process to have been
 * previously attached.  It *might* work if the program was
 * started via the normal ptrace (PTRACE_TRACEME).
 */

static void
detach_command (args, from_tty)
     char *args;
     int from_tty;
{
  dont_repeat ();			/* Not for the faint of heart */
  target_detach (args, from_tty);
}

/* ARGSUSED */
static void
float_info (addr_exp, from_tty)
     char *addr_exp;
     int from_tty;
{
#ifdef FLOAT_INFO
	FLOAT_INFO;
#else
	printf_filtered ("No floating point info available for this processor.\n");
#endif
}
\f
/* ARGSUSED */
static void
unset_command (args, from_tty)
     char *args;
     int from_tty;
{
  printf_filtered ("\"unset\" must be followed by the name of an unset subcommand.\n");
  help_list (unsetlist, "unset ", -1, gdb_stdout);
}

void
_initialize_infcmd ()
{
  struct cmd_list_element *c;
  
  add_com ("tty", class_run, tty_command,
	   "Set terminal for future runs of program being debugged.");

  add_show_from_set
    (add_set_cmd ("args", class_run, var_string_noescape, (char *)&inferior_args,
		  
"Set arguments to give program being debugged when it is started.\n\
Follow this command with any number of args, to be passed to the program.",
		  &setlist),
     &showlist);

  c = add_cmd
    ("environment", no_class, environment_info,
     "The environment to give the program, or one variable's value.\n\
With an argument VAR, prints the value of environment variable VAR to\n\
give the program being debugged.  With no arguments, prints the entire\n\
environment to be given to the program.", &showlist);
  c->completer = noop_completer;

  add_prefix_cmd ("unset", no_class, unset_command,
		  "Complement to certain \"set\" commands",
		  &unsetlist, "unset ", 0, &cmdlist);
  
  c = add_cmd ("environment", class_run, unset_environment_command,
	      "Cancel environment variable VAR for the program.\n\
This does not affect the program until the next \"run\" command.",
	   &unsetlist);
  c->completer = noop_completer;

  c = add_cmd ("environment", class_run, set_environment_command,
	       "Set environment variable value to give the program.\n\
Arguments are VAR VALUE where VAR is variable name and VALUE is value.\n\
VALUES of environment variables are uninterpreted strings.\n\
This does not affect the program until the next \"run\" command.",
	   &setlist);
  c->completer = noop_completer;
 
  add_com ("path", class_files, path_command,
       "Add directory DIR(s) to beginning of search path for object files.\n\
$cwd in the path means the current working directory.\n\
This path is equivalent to the $PATH shell variable.  It is a list of\n\
directories, separated by colons.  These directories are searched to find\n\
fully linked executable files and separately compiled object files as needed.");

  c = add_cmd ("paths", no_class, path_info,
	    "Current search path for finding object files.\n\
$cwd in the path means the current working directory.\n\
This path is equivalent to the $PATH shell variable.  It is a list of\n\
directories, separated by colons.  These directories are searched to find\n\
fully linked executable files and separately compiled object files as needed.", &showlist);
  c->completer = noop_completer;

 add_com ("attach", class_run, attach_command,
 	   "Attach to a process or file outside of GDB.\n\
This command attaches to another target, of the same type as your last\n\
`target' command (`info files' will show your target stack).\n\
The command may take as argument a process id or a device file.\n\
For a process id, you must have permission to send the process a signal,\n\
and it must have the same effective uid as the debugger.\n\
When using \"attach\", you should use the \"file\" command to specify\n\
the program running in the process, and to load its symbol table.");

  add_com ("detach", class_run, detach_command,
	   "Detach a process or file previously attached.\n\
If a process, it is no longer traced, and it continues its execution.  If you\n\
were debugging a file, the file is closed and gdb no longer accesses it.");

  add_com ("signal", class_run, signal_command,
	   "Continue program giving it signal specified by the argument.\n\
An argument of \"0\" means continue program without giving it a signal.");

  add_com ("stepi", class_run, stepi_command,
	   "Step one instruction exactly.\n\
Argument N means do this N times (or till program stops for another reason).");
  add_com_alias ("si", "stepi", class_alias, 0);

  add_com ("nexti", class_run, nexti_command,
	   "Step one instruction, but proceed through subroutine calls.\n\
Argument N means do this N times (or till program stops for another reason).");
  add_com_alias ("ni", "nexti", class_alias, 0);

  add_com ("finish", class_run, finish_command,
	   "Execute until selected stack frame returns.\n\
Upon return, the value returned is printed and put in the value history.");

  add_com ("next", class_run, next_command,
	   "Step program, proceeding through subroutine calls.\n\
Like the \"step\" command as long as subroutine calls do not happen;\n\
when they do, the call is treated as one instruction.\n\
Argument N means do this N times (or till program stops for another reason).");
  add_com_alias ("n", "next", class_run, 1);

  add_com ("step", class_run, step_command,
	   "Step program until it reaches a different source line.\n\
Argument N means do this N times (or till program stops for another reason).");
  add_com_alias ("s", "step", class_run, 1);

  add_com ("until", class_run, until_command,
	   "Execute until the program reaches a source line greater than the current\n\
or a specified line or address or function (same args as break command).\n\
Execution will also stop upon exit from the current stack frame.");
  add_com_alias ("u", "until", class_run, 1);
  
  add_com ("jump", class_run, jump_command,
	   "Continue program being debugged at specified line or address.\n\
Give as argument either LINENUM or *ADDR, where ADDR is an expression\n\
for an address to start at.");

  add_com ("continue", class_run, continue_command,
	   "Continue program being debugged, after signal or breakpoint.\n\
If proceeding from breakpoint, a number N may be used as an argument,\n\
which means to set the ignore count of that breakpoint to N - 1 (so that\n\
the breakpoint won't break until the Nth time it is reached).");
  add_com_alias ("c", "cont", class_run, 1);
  add_com_alias ("fg", "cont", class_run, 1);

  add_com ("run", class_run, run_command,
	   "Start debugged program.  You may specify arguments to give it.\n\
Args may include \"*\", or \"[...]\"; they are expanded using \"sh\".\n\
Input and output redirection with \">\", \"<\", or \">>\" are also allowed.\n\n\
With no arguments, uses arguments last specified (with \"run\" or \"set args\").\n\
To cancel previous arguments and run with no arguments,\n\
use \"set args\" without arguments.");
  add_com_alias ("r", "run", class_run, 1);

  add_info ("registers", nofp_registers_info,
    "List of integer registers and their contents, for selected stack frame.\n\
Register name as argument means describe only that register.");

  add_info ("all-registers", all_registers_info,
"List of all registers and their contents, for selected stack frame.\n\
Register name as argument means describe only that register.");

  add_info ("program", program_info,
	    "Execution status of the program.");

  add_info ("float", float_info,
	    "Print the status of the floating point unit\n");

  inferior_args = savestring ("", 1);	/* Initially no args */
  inferior_environ = make_environ ();
  init_environ (inferior_environ);
}

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: GDB problem
  1997-07-07 23:30     ` J.R. Dean
@ 1997-07-08  0:56       ` Geoffrey Noer
  1997-07-08  6:58         ` Stuart Williams
  0 siblings, 1 reply; 35+ messages in thread
From: Geoffrey Noer @ 1997-07-08  0:56 UTC (permalink / raw)
  To: J.R. Dean; +Cc: gnu-win32

J.R. Dean wrote:
> 
> >My main problem with the gdb in beta 18 is the crash on exit
> >problem.  I hope it will be fixed in future releases...
>
> Oh, so it *is* a bug?  Whoops.
> 
> Well, so much for debugging with gdb.

My consistent problem is quitting the tcl/tk gdb (I believe the problem
is actually in tcl/tk rather than in gdb).  That said, I find the b18 gdb
to be fairly usable so you may not need to completely abandon using it
because of this problem.

-- 
Geoffrey Noer
noer@cygnus.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: GDB problem
  1997-07-07 15:27   ` Geoffrey Noer
@ 1997-07-07 23:30     ` J.R. Dean
  1997-07-08  0:56       ` Geoffrey Noer
  0 siblings, 1 reply; 35+ messages in thread
From: J.R. Dean @ 1997-07-07 23:30 UTC (permalink / raw)
  To: Geoffrey Noer; +Cc: J.R. Dean, hamann, gnu-win32

At 02:52 PM 7/7/97 -0700, Geoffrey Noer wrote:
>J.R. Dean wrote:
>> 
>> I'm having the same problem, but I'm using gdb in command-
>> line mode in a DOS window.  I suspect we're encountering a 
>> configuration bug, but since b18 hasn't been out that long
>> there's nothing in the FAQ about the problem.
>
>My main problem with the gdb in beta 18 is the crash on exit
>problem.  I hope it will be fixed in future releases...
>
Oh, so it *is* a bug?  Whoops.

Well, so much for debugging with gdb.


-- Dean


-------------
jrd@enclave.org  --  bbs: jrd@nocturne.boulder-creek.ca.us
"The Enclave" -- Boulder Creek, California -- +1 408 336-0610
=+! Public Access Usenet BBS for Writers & Other Fiends !+=


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: GDB problem
  1997-07-06 15:34 ` J.R. Dean
@ 1997-07-07 15:27   ` Geoffrey Noer
  1997-07-07 23:30     ` J.R. Dean
  0 siblings, 1 reply; 35+ messages in thread
From: Geoffrey Noer @ 1997-07-07 15:27 UTC (permalink / raw)
  To: J.R. Dean; +Cc: hamann, gnu-win32

J.R. Dean wrote:
> 
> I'm having the same problem, but I'm using gdb in command-
> line mode in a DOS window.  I suspect we're encountering a 
> configuration bug, but since b18 hasn't been out that long
> there's nothing in the FAQ about the problem.

My main problem with the gdb in beta 18 is the crash on exit
problem.  I hope it will be fixed in future releases...

-- 
Geoffrey Noer
noer@cygnus.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: GDB problem
  1997-07-06  4:46 Mark Hamann
@ 1997-07-06 15:34 ` J.R. Dean
  1997-07-07 15:27   ` Geoffrey Noer
  0 siblings, 1 reply; 35+ messages in thread
From: J.R. Dean @ 1997-07-06 15:34 UTC (permalink / raw)
  To: Mark Hamann; +Cc: gnu-win32

At 07:13 PM 7/6/97 +0900, Mark Hamann wrote:
>I have just installed the Win32 tools in Windows 95 and I am having some
>problems.  The GDB environment is very unstable.  It causes my system to
>crash or causes bash to hang up when the debugged program finishes or I use
>the 'kill' command or I use the 'close' from the menu bar.  I can use
>'quit' from the menu bar, but I still have to hit ctrl-alt-del and
>terminate the task manually.  I would invoke the command line version if I
>had an xterm or the DOS prompt had scrollbars.  Is there something I can
>do?
>
Mark,

I'm having the same problem, but I'm using gdb in command-
line mode in a DOS window.  I suspect we're encountering a 
configuration bug, but since b18 hasn't been out that long
there's nothing in the FAQ about the problem.


-- Dean


-------------
jrd@enclave.org  --  bbs: jrd@nocturne.boulder-creek.ca.us
"The Enclave" -- Boulder Creek, California -- +1 408 336-0610
=+! Public Access Usenet BBS for Writers & Other Fiends !+=


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 35+ messages in thread

* GDB problem
@ 1997-07-06  4:46 Mark Hamann
  1997-07-06 15:34 ` J.R. Dean
  0 siblings, 1 reply; 35+ messages in thread
From: Mark Hamann @ 1997-07-06  4:46 UTC (permalink / raw)
  To: gnu-win32

I have just installed the Win32 tools in Windows 95 and I am having some
problems.  The GDB environment is very unstable.  It causes my system to
crash or causes bash to hang up when the debugged program finishes or I use
the 'kill' command or I use the 'close' from the menu bar.  I can use
'quit' from the menu bar, but I still have to hit ctrl-alt-del and
terminate the task manually.  I would invoke the command line version if I
had an xterm or the DOS prompt had scrollbars.  Is there something I can
do?

I looked through the archives for this question, but I didn't see it.  All
of the questions looked like a higher level than this and everyone seems to
be using NT, so accept my apologies. Maybe someday I will know what I am
doing and my company will take OS's seriously and switch from 95 to NT;->.

Thanks,
Mark Hamann

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 35+ messages in thread

end of thread, other threads:[~2012-05-05  1:58 UTC | newest]

Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-06-02  5:50 gdb problem Tom M. Yeh
  -- strict thread matches above, loose matches on Subject: below --
2011-10-22 20:38 Ken Brown
2011-10-23  2:37 ` jan.kolar
2011-10-23 19:04 ` Christopher Faylor
2011-10-23 21:48   ` Ken Brown
2012-05-03 20:05     ` Ken Brown
2012-05-04  3:10       ` Christopher Faylor
2012-05-04 19:20         ` Ken Brown
2012-05-05  1:58           ` Ryan Johnson
2004-01-27 14:50 RS
2004-01-28  0:02 ` Christopher Faylor
2004-01-26 20:04 RS
2004-01-26 20:38 ` Christopher Faylor
2001-08-28  0:59 Gdb problem Wolfgang Fritz
2001-08-28  0:45 problem Jorge Goncalvez
2001-08-28  0:55 ` Gdb problem Andrew Markebo
     [not found] <NFBBJHGBKLKEAOHMECHMEEDECAAA.yrwang@cc.nctu.edu.tw>
2001-05-22  3:12 ` gdb problem egor duda
2000-06-02  6:25 Earnie Boyd
2000-06-02  8:32 ` Chris Faylor
2000-06-02 10:02 ` Jonathan Larmour
2000-06-02 10:03   ` Jonathan Larmour
1999-03-29 12:22 Igor Sheyn
1999-03-29 16:45 ` Chris Faylor
1999-03-31 19:45   ` Chris Faylor
1999-03-31 19:45 ` Igor Sheyn
1997-10-29 17:22 GDB Problem Sudhakar Ganti
1997-10-30  5:48 ` Chris Faylor
1997-09-24  6:57 Bardley09
1997-07-09  5:31 GDB problem Bryan Rosenburg
1997-07-08  6:58 Bryan Rosenburg
1997-07-06  4:46 Mark Hamann
1997-07-06 15:34 ` J.R. Dean
1997-07-07 15:27   ` Geoffrey Noer
1997-07-07 23:30     ` J.R. Dean
1997-07-08  0:56       ` Geoffrey Noer
1997-07-08  6:58         ` Stuart Williams

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).