On Tue, Mar 20, 2012 at 4:21 PM, Dani Moncayo <dmonc...@gmail.com> wrote:
> At this point, the *input/output of p1.exe* buffer should show the
> "hello, world!" message written to the standard output, right? But I
> observe that the buffer remains empty (see attached screenshot).
Just a guess:
There is no newline in the intended output, so perhaps the output isn't
flushed yet. Does it appear if you step through the rest of the program?
Dani Moncayo wrote:
> > There is no newline in the intended output, so perhaps the output isn't
> > flushed yet. Does it appear if you step through the rest of the program?
> I've tried it and not, it never appears, even after I've reached the
> end of the program.
Please add a newline to the output. I think that without the newline
the output may be covered by other output. I think it likely that the
output is actually being output but just covered.
-g produces debug information in the default format, maybe you need to use -ggdb to get "debug information in default extended format". (It might also be useful to try the build with the additional switches -feliminate-unused-debug-symbols and -feliminate-unused-debug-types.)
> Please add a newline to the output. I think that without the newline
> the output may be covered by other output. I think it likely that the
> output is actually being output but just covered.
If that was the case, it would cause a lot of confusion to users, but
fortunately, that's not the case (I've just tested it and I see no
output either).
> -g produces debug information in the default format, maybe you need to use -ggdb to get "debug information in default extended format". (It might also be useful to try the build with the additional switches -feliminate-unused-debug-symbols and -feliminate-unused-debug-types.)
I've just tried to compile like this:
gcc -ggdb --all-warnings -Wall -Wextra
-feliminate-unused-debug-symbols -feliminate-unused-debug-types -o
p1.exe main.c
Dani Moncayo writes:
>> Please add a newline to the output. I think that without the newline
>> the output may be covered by other output. I think it likely that the
>> output is actually being output but just covered.
> If that was the case, it would cause a lot of confusion to users, but
> fortunately, that's not the case (I've just tested it and I see no
> output either).
I also think it's a buffering issue. For me, it makes a difference to
put the \n or not. It also happens if I put a fflush(0) statement after
the printf().
Your unmodified example works for me if I run the program into gdb with
the 'r' command.
Dani Moncayo wrote:
> > Please add a newline to the output. I think that without the newline
> > the output may be covered by other output. I think it likely that the
> > output is actually being output but just covered.
> If that was the case, it would cause a lot of confusion to users, but
> fortunately, that's not the case (I've just tested it and I see no
> output either).
It may be confusing but it is no different from having this case:
Question: Where did the output go? Answer: It was printed but then it
was covered by the prompt and effectively hidden. Here I am using two
printf statements because your program didn't include one but in the
operation of gdm and emacs there is almost certainly one, which is
represented here by the second printf.
But since you say it didn't make any difference then this point isn't
relevant. But at least you can see why I asked for the newline.
At this point I do not have any more information. Good luck!
>> If that was the case, it would cause a lot of confusion to users, but
>> fortunately, that's not the case (I've just tested it and I see no
>> output either).
> It may be confusing but it is no different from having this case:
> Question: Where did the output go? Answer: It was printed but then it
> was covered by the prompt and effectively hidden. Here I am using two
> printf statements because your program didn't include one but in the
> operation of gdm and emacs there is almost certainly one, which is
> represented here by the second printf.
Thanks for the explanation, but what I wanted to say is that the users
expect that the "input/output" buffer in Emacs contains _exclusively_
the input/output text sent to/taken from the process, and in this
case, the process does not write any "\r" character.
In any case, as you said, this doesn't seem to be the origin of the problem.
> I'm trying to test the Emacs gdb interface, but there is something I
> don't yet understand.
> This is my setup:
> * OS: MS-Windows 7.
> * Development Environment: MinGW.
> I've done this:
> * I've written a "hello world" program [1].
> * I've compiled it.
> * I've tested the executable (p1.exe), and it works fine.
> Now, from my Emacs (almost latest trunk) I've done:
> * M-x gdb RET (the default command was "gdb -i=mi p1.exe")
> * b main RET
> * run RET
> * M-x gdb-many-windows RET
> * n RET
> At this point, the *input/output of p1.exe* buffer should show the
> "hello, world!" message written to the standard output, right? But I
> observe that the buffer remains empty (see attached screenshot).
> Probably I'm missing something here. Do you know what?
Did you try to run it under bare gdb (without Emacs)? If the problem
remains, it's gdb issue rather than Emacs one.
> Did you try to run it under bare gdb (without Emacs)? If the problem
> remains, it's gdb issue rather than Emacs one.
Good question. I've just debugged the program directly under gdb
(invoked from a cmd.exe console) and everything looks fine (I see the
"hello, world" message).
Debugger mode is derived from comint mode which, by design, doesn't display output until it gets to the end of a line.
A few details, if you care:
>From the other side, gdb doesn't see anything you type until you type <ENTER>, invoking (comint-send-input) and as a consequence calls the comint-input-filter-functions.
I think the corresponding function for output is (comint-output-filter).
These things usually do good things for you, like hide passwords.
An experiment (under *NIX), if you want an example of what comint doesn't show you:
Get a shell buffer and type 'stty sane'. (This cooks the terminal. Comint intentionally makes it raw to control I/O.
Now type a command like 'echo Your name here.'
You will also see the command since the terminal now echoes its input too.
(No, I don't know how to do this on Windows and I don't know something that corresponds for gdb. Sorry.)
-----Original Message-----
From: help-gnu-emacs-bounces+dougl=shubertticketing....@gnu.org [mailto:help-gnu-emacs-bounces+dougl=shubertticketing....@gnu.org] On Behalf Of Dani Moncayo
Sent: Wednesday, 2012 March 21 08:11
To: Sergei Organov
> Did you try to run it under bare gdb (without Emacs)? If the problem
> remains, it's gdb issue rather than Emacs one.
Good question. I've just debugged the program directly under gdb
(invoked from a cmd.exe console) and everything looks fine (I see the
"hello, world" message).
> > There is no newline in the intended output, so perhaps the output isn't
> > flushed yet. Does it appear if you step through the rest of the program?
> I've tried it and not, it never appears, even after I've reached the
> end of the program.
If you add the newline, the output appears at the end, but not in the
input/output buffer.
If there's no newline, I wouldn't expect the output to appear at all,
in such a short program, since standard output redirected to pipes is
fully-buffered on Windows, not line-buffered as on Posix systems.
> If you add the newline, the output appears at the end, but not in the
> input/output buffer.
> If there's no newline, I wouldn't expect the output to appear at all,
> in such a short program, since standard output redirected to pipes is
> fully-buffered on Windows, not line-buffered as on Posix systems.
Ok, I understand that Emacs can't show the output until it is flushed,
but when it is, as (for example) in this case:
-------- main.c -------------
#include <stdio.h>
int main(void)
{
printf("hello, world!\n");
fflush(stdout);
return 0;
}
-----------------------------
The output should not be shown in the *gud* buffer (as happens now),
but in the *input/output* one, no? If not, what's that *input/output*
buffer for?
> The output should not be shown in the *gud* buffer (as happens now),
> but in the *input/output* one, no? If not, what's that *input/output*
> buffer for?
I suspect that whatever tricks gdb-mi.el uses to separate the
program's output from GDB's simply doesn't work on Windows. But
that's a guess, I didn't have time to dig into this.
