Re: gdb-ui almosts works in NT

Re: gdb-ui almosts works in NT

[Eli Zaretskii]

[Redirected to emacs-devel.]
> Date: Fri, 28 Mar 2003 14:29:14 -0500
> From: Jonathan Luntz <jluntz@umich.edu>
> 
> I'm not usre if this classifies as a bug

IMHO, it does.

> I'm trying to get gdba
> working under NT Emacs.  Almost everything works.  One minor issue is
> that gdb-ui.el is hardcoded at one point to use "/bin/cat", so I just
> put a copy of the msys (mingw) cat.exe there.

It's wrong for Emacs to use such code, IMHO.  It should either invoke
`cat' (and let it be found along PATH), or, better, implement some
code that would eliminate the need for an external program altogether,
since `cat' is not guaranteed to be available on every platform
supported by Emacs.

It strikes me that it woyldn't be hard to eliminate the need for
`cat', since Emacs already has a means to visit files.

> The only problem is I can't
> get the program IO to run in the input/output window in emacs.  It
> runs always in its own DOS window.

What compiler did you use to compile that program?  Was that MinGW's
GCC?

Re: gdb-ui almosts works in NT

[Stefan Monnier]

> > I'm trying to get gdba
> > working under NT Emacs.  Almost everything works.  One minor issue is
> > that gdb-ui.el is hardcoded at one point to use "/bin/cat", so I just
> > put a copy of the msys (mingw) cat.exe there.
> 
> It's wrong for Emacs to use such code, IMHO.  It should either invoke
> `cat' (and let it be found along PATH), or, better, implement some
> code that would eliminate the need for an external program altogether,
> since `cat' is not guaranteed to be available on every platform
> supported by Emacs.

Ielm was recently changed to use `hexl' as a replacement for `cat'.
We should probably do the same here.


	Stefan

Re: gdb-ui almosts works in NT

[Jonathan Luntz]

[-- Attachment #1.1: Type: text/plain, Size: 1635 bytes --]



Eli Zaretskii wrote:

>[Redirected to emacs-devel.]
>  
>
>>Date: Fri, 28 Mar 2003 14:29:14 -0500
>>From: Jonathan Luntz <jluntz@umich.edu>
>>
>>I'm not usre if this classifies as a bug
>>    
>>
>
>IMHO, it does.
>
>  
>
>>I'm trying to get gdba
>>working under NT Emacs.  Almost everything works.  One minor issue is
>>that gdb-ui.el is hardcoded at one point to use "/bin/cat", so I just
>>put a copy of the msys (mingw) cat.exe there.
>>    
>>
>
>It's wrong for Emacs to use such code, IMHO.  It should either invoke
>`cat' (and let it be found along PATH), or, better, implement some
>code that would eliminate the need for an external program altogether,
>since `cat' is not guaranteed to be available on every platform
>supported by Emacs.
>
>It strikes me that it woyldn't be hard to eliminate the need for
>`cat', since Emacs already has a means to visit files.
>
>  
>
>>The only problem is I can't
>>get the program IO to run in the input/output window in emacs.  It
>>runs always in its own DOS window.
>>    
>>
>
>What compiler did you use to compile that program?  Was that MinGW's
>GCC?
>

Yes - I used mingw to compile:
C:> g++ --version
g++ (GCC) 3.2 (mingw special 20020817-1)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


My code is very simple:

#include <iostream>
using namespace std;
int main()
{
  int i;
  for (i=1; i<100; i++) {
    //printf("hello world %i\n",i);
    cout << "hello world " << j << "\n";
  }
}

neither printf nor cout work.

Jon

[-- Attachment #1.2: Type: text/html, Size: 2435 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: gdb-ui almosts works in NT

[Eli Zaretskii]

> Date: Mon, 31 Mar 2003 11:38:06 -0500
> From: Jonathan Luntz <jluntz@umich.edu>
> 
> Yes - I used mingw to compile:
> C:> g++ --version
> g++ (GCC) 3.2 (mingw special 20020817-1)
> Copyright (C) 2002 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> 
> My code is very simple:
> 
> #include <iostream>
> using namespace std;
> int main()
> {
>   int i;
>   for (i=3D1; i<100; i++) {
>     //printf("hello world %i\n",i);
>     cout << "hello world " << j << "\n";
>   }
> }
> 
> neither printf nor cout work.

I suspect that this is due to how the Windows runtime implements
inherited handles (as opposed to Unix, which is what GDB and Emacs
basically assume).

Unfortunately, I don't know enough about MinGW and the Windows runtime
routines, so I'd suggest asking this question on the MinGW mailing
list.

Re: gdb-ui almosts works in NT

[Nick Roberts]

> > I'm trying to get gdba
> > working under NT Emacs.  Almost everything works.  One minor issue is
> > that gdb-ui.el is hardcoded at one point to use "/bin/cat", so I just
> > put a copy of the msys (mingw) cat.exe there.

> It's wrong for Emacs to use such code, IMHO.  It should either invoke
> `cat' (and let it be found along PATH), 

I agree. I'll make this change.

> or, better, implement some
> code that would eliminate the need for an external program altogether,
> since `cat' is not guaranteed to be available on every platform
> supported by Emacs.

> It strikes me that it woyldn't be hard to eliminate the need for
> `cat', since Emacs already has a means to visit files.

The output from the inferior could be sent directly to the input/output buffer
but the author of this part of the code from gdba.el (Tom Lord?) used cat
because:

;; We want to use comint because it has various nifty and familiar
;; features.  We don't need a process, but comint wants one, so create
;; a dummy one.
(make-comint-in-buffer
(substring (buffer-name) 1 (- (length (buffer-name)) 1))
(current-buffer) "/bin/cat")

> > The only problem is I can't
> > get the program IO to run in the input/output window in emacs.  It
> > runs always in its own DOS window.

> What compiler did you use to compile that program?  Was that MinGW's
> GCC?

I downloaded Emacs for NT and MinGW for the first time today and this didn't
seem to be just a problem with gdb-ui.el. `M-x gdb' from gud.el also sent the
output from the inferior to its own DOS window. Even if `gdb mytest' is run in
a DOS window (no Emacs) then the inferior outputs to its own DOS window and
does not seem able to share the window with gdb like in GNU/Linux.

However, I have no real experience with Emacs for NT, so if you can see changes
that will make it work for this platform too, please install them.

Nick

Re: gdb-ui almosts works in NT

[Eli Zaretskii]

> From: Nick Roberts <nick@nick.uklinux.net>
> Date: Mon, 31 Mar 2003 22:04:00 +0100
> 
> The output from the inferior could be sent directly to the input/output buffer
> but the author of this part of the code from gdba.el (Tom Lord?) used cat
> because:
> 
> ;; We want to use comint because it has various nifty and familiar
> ;; features.  We don't need a process, but comint wants one, so create
> ;; a dummy one.

I don't understand why is this important; perhaps someone else does.

> I downloaded Emacs for NT and MinGW for the first time today and this didn't
> seem to be just a problem with gdb-ui.el. `M-x gdb' from gud.el also sent the
> output from the inferior to its own DOS window. Even if `gdb mytest' is run in
> a DOS window (no Emacs) then the inferior outputs to its own DOS window and
> does not seem able to share the window with gdb like in GNU/Linux.

Yes, I suspected that much.  Thanks for verifying.

Re: gdb-ui almosts works in NT

[Edward O'Connor]

>> The output from the inferior could be sent directly to the
>> input/output buffer but the author of this part of the code from
>> gdba.el (Tom Lord?) used cat because:
>> 
>> ;; We want to use comint because it has various nifty and familiar
>> ;; features. We don't need a process, but comint wants one, so create
>> ;; a dummy one.
> 
> I don't understand why is this important; perhaps someone else does.

FYI, IELM had a similar problem, which has been fixed like so:

    ;; Was cat, but on non-Unix platforms that might not exist, so
    ;; use hexl instead, which is part of the Emacs distribution.
    (condition-case nil
	(start-process "ielm" (current-buffer) "hexl")
      (file-error (start-process "ielm" (current-buffer) "cat")))


Ted

-- 
Edward O'Connor
ted@oconnor.cx

Ense petit placidam sub libertate quietem.

Re: gdb-ui almosts works in NT

[Nick Roberts]

 > >> The output from the inferior could be sent directly to the
 > >> input/output buffer but the author of this part of the code from
 > >> gdba.el (Tom Lord?) used cat because:
 > >> 
 > >> ;; We want to use comint because it has various nifty and familiar
 > >> ;; features. We don't need a process, but comint wants one, so create
 > >> ;; a dummy one.
 > > 
 > > I don't understand why is this important; perhaps someone else does.

I don't know if its important but it gives the user features like accessing
previous input (C-p) and to send signals to the inferior (although this can
probably be done from the GUD buffer).

 > FYI, IELM had a similar problem, which has been fixed like so:
 > 
 >     ;; Was cat, but on non-Unix platforms that might not exist, so
 >     ;; use hexl instead, which is part of the Emacs distribution.
 >     (condition-case nil
 > 	(start-process "ielm" (current-buffer) "hexl")
 >       (file-error (start-process "ielm" (current-buffer) "cat")))

There appear to be two problems:

1) gdb-ui doesn't output to the I/O buffer in NT.
2) cat might not exist in NT.

To solve 1) I propose to get rid of the I/O buffer in NT. Then 2) would
no longer be an issue as cat (or hexl) would not be needed in NT. To do this
(and cover Windows NT/2K/9X/ME?) what case should I consider?

(eq system-type 'windows-nt)?
(memq system-type '(ms-dos windows-nt))?
something else?

Nick

Re: gdb-ui almosts works in NT

[Stefan Monnier]

> I don't know if its important but it gives the user features like accessing
> previous input (C-p) and to send signals to the inferior (although this can
> probably be done from the GUD buffer).

I don't think sending signals work.  But if you want the I/O
buffer to be more than just O, then the comint package is a good
way to take care of the I part.

> There appear to be two problems:
> 
> 1) gdb-ui doesn't output to the I/O buffer in NT.

Are you sure this is the always the case ?
I think it does not depend on gdb-ui but on the underlying gdb session,
so it might depend on which gdb executable you're using (native port,
mingw, cygwin, dos, godknowswhatelse, ...) and on what kind of runtime
library is used by the debugged program (again, native, cygwin,
djgpp, ...).

Not having used w32 much more than to play solitaire, I really have
no idea what I'm talking about, but it seems like it's not obviously
true that "gdb-ui doesn't output to the I/O buffer in NT" in all
circumstances.  Could someone who knows better (Jason? Eli?) pipe in?


	Stefan

Re: gdb-ui almosts works in NT

[Eli Zaretskii]

> From: Nick Roberts <nick@nick.uklinux.net>
> Date: Tue, 1 Apr 2003 22:06:17 +0100
> 
> 1) gdb-ui doesn't output to the I/O buffer in NT.
> 2) cat might not exist in NT.
> 
> To solve 1) I propose to get rid of the I/O buffer in NT. Then 2) would
> no longer be an issue as cat (or hexl) would not be needed in NT. To do this
> (and cover Windows NT/2K/9X/ME?) what case should I consider?
> 
> (eq system-type 'windows-nt)?
> (memq system-type '(ms-dos windows-nt))?
> something else?

The MSDOS port doesn't support async subprocesses, and thus GUD
doesn't work in that port.  But it does no harm to mention the MSDOS
port in the ones that need this special treatment (for the unprobable
case that someone will add subprocesses support to it in the future),
so my vote is for the second variant of the above two clauses.

Re: gdb-ui almosts works in NT

[Eli Zaretskii]

> From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
> Date: Tue, 01 Apr 2003 16:31:35 -0500
> > 
> > 1) gdb-ui doesn't output to the I/O buffer in NT.
> 
> Are you sure this is the always the case ?
> I think it does not depend on gdb-ui but on the underlying gdb session,
> so it might depend on which gdb executable you're using (native port,
> mingw, cygwin, dos, godknowswhatelse, ...) and on what kind of runtime
> library is used by the debugged program (again, native, cygwin,
> djgpp, ...).

Just FYI: the DOS port uses only the DJGPP library and runtime, there
is no other DOS configuration of Emacs that one can build, not for
years.

As for Cygwin, this problem might indeed not happen there (and then
again it might), but the clause suggested by Nick didn't include the
`cygwin' configuration, so I think it's safe.  Someone who has the
Cygwin build handy should try this and tell what they found; until
then, I think we should assume it's Unix-like.

Re: gdb-ui almosts works in NT

[Stefan Monnier]

> > From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
> > Date: Tue, 01 Apr 2003 16:31:35 -0500
> > > 
> > > 1) gdb-ui doesn't output to the I/O buffer in NT.
> > 
> > Are you sure this is the always the case ?
> > I think it does not depend on gdb-ui but on the underlying gdb session,
> > so it might depend on which gdb executable you're using (native port,
> > mingw, cygwin, dos, godknowswhatelse, ...) and on what kind of runtime
> > library is used by the debugged program (again, native, cygwin,
> > djgpp, ...).
> 
> Just FYI: the DOS port uses only the DJGPP library and runtime, there
> is no other DOS configuration of Emacs that one can build, not for
> years.
> 
> As for Cygwin, this problem might indeed not happen there (and then
> again it might), but the clause suggested by Nick didn't include the
> `cygwin' configuration, so I think it's safe.  Someone who has the
> Cygwin build handy should try this and tell what they found; until
> then, I think we should assume it's Unix-like.

But aren't we talking about different things.
I was talking about how gdb and the debugged program were built,
whereas you're talking about how Emacs is built.  Aren't those
two aspects somewhat orthogonal ?  Can't I run a cygwin gdb within
NTemacs ?
I think a better solution would be to make the creation and/or display
of the I/O buffer conditional on the presence of output.
Or something like that.


	Stefan

Re: gdb-ui almosts works in NT

[Jonathan Luntz]

[-- Attachment #1.1: Type: text/plain, Size: 1397 bytes --]



Eli Zaretskii wrote:

>>From: Nick Roberts <nick@nick.uklinux.net>
>>Date: Mon, 31 Mar 2003 22:04:00 +0100
>>
>>The output from the inferior could be sent directly to the input/output buffer
>>but the author of this part of the code from gdba.el (Tom Lord?) used cat
>>because:
>>
>>;; We want to use comint because it has various nifty and familiar
>>;; features.  We don't need a process, but comint wants one, so create
>>;; a dummy one.
>>    
>>
>
>I don't understand why is this important; perhaps someone else does.
>
>  
>
>>I downloaded Emacs for NT and MinGW for the first time today and this didn't
>>seem to be just a problem with gdb-ui.el. `M-x gdb' from gud.el also sent the
>>output from the inferior to its own DOS window. Even if `gdb mytest' is run in
>>a DOS window (no Emacs) then the inferior outputs to its own DOS window and
>>does not seem able to share the window with gdb like in GNU/Linux.
>>    
>>
>
>Yes, I suspected that much.  Thanks for verifying.
>

I found something useful.  If you do the command "set new-console off" 
at the gdb prompt, it does not open an new dos window, and everything 
works properly.  It only works if you do NOT put a -fullname switch on 
the gdb command line.  I suppose the right solution would be to have 
gdba automatically execute set new-console off when it starts up (I 
don;t think there's a command line switch for it.)

Jon

[-- Attachment #1.2: Type: text/html, Size: 1947 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: gdb-ui almosts works in NT

[Eli Zaretskii]

> From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
> Date: Wed, 02 Apr 2003 09:14:34 -0500
> 
> But aren't we talking about different things.
> I was talking about how gdb and the debugged program were built,
> whereas you're talking about how Emacs is built.  Aren't those
> two aspects somewhat orthogonal ?  Can't I run a cygwin gdb within
> NTemacs ?

Not really: I won't recommend mixing GDB and Emacs ports like that.
Cygwin programs have their specific tricks that are only compatible
with other Cygwin programs.

Re: gdb-ui almosts works in NT

[Jason Rumney]

"Eli Zaretskii" <eliz@elta.co.il> writes:

> Not really: I won't recommend mixing GDB and Emacs ports like that.
> Cygwin programs have their specific tricks that are only compatible
> with other Cygwin programs.

There are workarounds that let Emacs recognize those tricks in some
circumstances. I'm not sure if gdb is one of those.

Re changing gdb-ui to not use the IO buffer; what does this mean in
terms of functionality?  As far as I can tell from the description of
the problem so far, the heart of the problem is that the mingw port
of gdb launches a separate window, even when invoked from the
command-line. It seems like we should be asking the mingw developers
to change this, rather than coming up with workarounds that leave all
versions of gdb less functional on Windows.

RE: gdb-ui almosts works in NT

[Nick Roberts]

> I found something useful.  If you do the command "set new-console off" 
> at the gdb prompt, it does not open an new dos window, and everything 
> works properly.  It only works if you do NOT put a -fullname switch on 
> the gdb command line.  I suppose the right solution would be to have 
> gdba automatically execute set new-console off when it starts up (I 
> don;t think there's a command line switch for it.)

I've looked at this and it seems to work for the simple program that you gave. If, however, you set a breakpoint in your for loop or you add a read
statement then there are buffering problems that I can only solve by using
fflush in my program. Is it possible for GDB or Emacs to flush the inferior?

Nick

Re: gdb-ui almosts works in NT

[Jonathan Luntz]

[-- Attachment #1.1: Type: text/plain, Size: 866 bytes --]



Nick Roberts wrote:

>  
>
>>I found something useful.  If you do the command "set new-console off" 
>>at the gdb prompt, it does not open an new dos window, and everything 
>>works properly.  It only works if you do NOT put a -fullname switch on 
>>the gdb command line.  I suppose the right solution would be to have 
>>gdba automatically execute set new-console off when it starts up (I 
>>don;t think there's a command line switch for it.)
>>    
>>
>
>I've looked at this and it seems to work for the simple program that you gave. If, however, you set a breakpoint in your for loop or you add a read
>statement then there are buffering problems that I can only solve by using
>fflush in my program. Is it possible for GDB or Emacs to flush the inferior?
>
>Nick
>

I get the same behavior - the flushing doesn't occur until the next time 
I read in the loop.

[-- Attachment #1.2: Type: text/html, Size: 1270 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel