* Separating "shell dir" output from GDB/MI output @ 2005-10-09 5:19 jingzhao.ou 2005-10-09 12:33 ` Bob Rossi 0 siblings, 1 reply; 13+ messages in thread From: jingzhao.ou @ 2005-10-09 5:19 UTC (permalink / raw) To: gdb Dear all, I am trying to see if it is possible to build a Tcl/Tk based GDB frontend using Bob Rossi's MI parser. For normal commands, it works just fine. However, if I execute "shell dir" command in gdb, the parser will report error. (see the end of the email) I am wondering if there is any way to separate the shell output from the normal GDB output. So that this problem can be solved properly. Sincerely hope that any one can give me a hand. I am using MinGW. Best regards, Jingzhao =========================================== (gdb) &"shell dir\n" Makefile gdbmi_grammar.tab.o gdbmi_pt.c main.tcl Makefile_orig gdbmi_grammar.txt gdbmi_pt.h tkGDB.c b gdbmi_grammar.y gdbmi_pt.o tkGDB.dll bb gdbmi_lexer.l lex.yy.c tkGDB.exe gdbmi_driver.c gdbmi_parser.c lex.yy.o tkGDB_bak.c gdbmi_grammar.tab.c gdbmi_parser.h libgdbmi_parser.a tkGDB_stub.c gdbmi_grammar.tab.h gdbmi_parser.o main.exe tk_gdb.tcl ^done (gdb) =========================================== ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Separating "shell dir" output from GDB/MI output 2005-10-09 5:19 Separating "shell dir" output from GDB/MI output jingzhao.ou @ 2005-10-09 12:33 ` Bob Rossi 2005-10-09 17:04 ` jingzhao.ou 2005-10-15 12:27 ` Eli Zaretskii 0 siblings, 2 replies; 13+ messages in thread From: Bob Rossi @ 2005-10-09 12:33 UTC (permalink / raw) To: jingzhao.ou; +Cc: gdb On Sat, Oct 08, 2005 at 10:19:33PM -0700, jingzhao.ou wrote: > Dear all, > > I am trying to see if it is possible to build a Tcl/Tk based GDB > frontend using Bob Rossi's MI parser. For normal commands, it works > just fine. However, if I execute "shell dir" command in gdb, the > parser will report error. (see the end of the email) > > I am wondering if there is any way to separate the shell output from > the normal GDB output. So that this problem can be solved properly. > > Sincerely hope that any one can give me a hand. I am using MinGW. > > Best regards, > Jingzhao > > =========================================== > (gdb) > &"shell dir\n" > Makefile gdbmi_grammar.tab.o gdbmi_pt.c main.tcl > Makefile_orig gdbmi_grammar.txt gdbmi_pt.h tkGDB.c > b gdbmi_grammar.y gdbmi_pt.o tkGDB.dll > bb gdbmi_lexer.l lex.yy.c tkGDB.exe > gdbmi_driver.c gdbmi_parser.c lex.yy.o tkGDB_bak.c > gdbmi_grammar.tab.c gdbmi_parser.h libgdbmi_parser.a tkGDB_stub.c > gdbmi_grammar.tab.h gdbmi_parser.o main.exe tk_gdb.tcl > ^done > (gdb) > =========================================== I think the best idea we've had so far for solving problems like this is to add an option to GDB to have it output GDB/MI data on a file descriptor X. For instance, gdb -i=mi -mi-out-fd=30 and then when you fork/exec GDB you dup the 30 file descriptor so that you can read the output. Eli, do you know if this approach would be portable to windows nativly? I could look into implementing this feature, since it would resolve a *lot* of problems regarding I/O. Thanks, Bob Rossi ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Separating "shell dir" output from GDB/MI output 2005-10-09 12:33 ` Bob Rossi @ 2005-10-09 17:04 ` jingzhao.ou 2005-10-09 17:12 ` Daniel Jacobowitz 2005-10-15 12:27 ` Eli Zaretskii 1 sibling, 1 reply; 13+ messages in thread From: jingzhao.ou @ 2005-10-09 17:04 UTC (permalink / raw) To: jingzhao.ou, gdb Thanks a lot for the reply. I really like your idea if it can be supported on both Windows and Linux platforms. I have another problem with MI. I want to provide a GDB console in my application so that the user can work with GDB directly if needed. However, if I enable the MI interpreter, the normal GDB output is suppressed. I hope that two interpreters can work at the same time and their outputs are directed to two different output file descriptors. This would give me exactly what I want and all I need. :-) Again, thanks! Best regards, Jingzhao On 10/9/05, Bob Rossi <bob@brasko.net> wrote: > I think the best idea we've had so far for solving problems like this is > to add an option to GDB to have it output GDB/MI data on a file > descriptor X. For instance, > gdb -i=mi -mi-out-fd=30 > and then when you fork/exec GDB you dup the 30 file descriptor so that > you can read the output. > > Eli, do you know if this approach would be portable to windows nativly? > I could look into implementing this feature, since it would resolve a > *lot* of problems regarding I/O. > > Thanks, > Bob Rossi > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Separating "shell dir" output from GDB/MI output 2005-10-09 17:04 ` jingzhao.ou @ 2005-10-09 17:12 ` Daniel Jacobowitz 2005-10-09 17:33 ` Bob Rossi ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: Daniel Jacobowitz @ 2005-10-09 17:12 UTC (permalink / raw) To: jingzhao.ou; +Cc: gdb On Sun, Oct 09, 2005 at 10:04:36AM -0700, jingzhao.ou wrote: > I have another problem with MI. I want to provide a GDB console in my > application so that the user can work with GDB directly if needed. > However, if I enable the MI interpreter, the normal GDB output is > suppressed. I hope that two interpreters can work at the same time and > their outputs are directed to two different output file descriptors. > This would give me exactly what I want and all I need. :-) We're a long way from being able to have multiple interpreters active at the same time. I agree it would be a good feature to have, and I've got other uses for it (in scripting). For now, for a console, you can use -interpreter-exec and get things more or less right. You can find a lot more about this in the list archives, e.g. Apple's console-quoted hack. > On 10/9/05, Bob Rossi <bob@brasko.net> wrote: > > I think the best idea we've had so far for solving problems like this is > > to add an option to GDB to have it output GDB/MI data on a file > > descriptor X. For instance, > > gdb -i=mi -mi-out-fd=30 > > and then when you fork/exec GDB you dup the 30 file descriptor so that > > you can read the output. > > > > Eli, do you know if this approach would be portable to windows nativly? > > I could look into implementing this feature, since it would resolve a > > *lot* of problems regarding I/O. While I think this is a good idea, what other specific problems would it solve that we haven't solved already? A simpler and more specific solution for this particular problem would be to run "shell" through pipes and MI encapsulate its output, to prevent it from playing with the user's terminal. I think that's a good idea anyway. Right now, you can probably use interactive commands via shell, but I believe that most uses of it are for things like ls, grep, or make. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Separating "shell dir" output from GDB/MI output 2005-10-09 17:12 ` Daniel Jacobowitz @ 2005-10-09 17:33 ` Bob Rossi 2005-10-09 20:02 ` Daniel Jacobowitz [not found] ` <b5706cf10510091145v5bfa03ben44f62981f174c4a2@mail.gmail.com> 2005-10-15 12:29 ` Eli Zaretskii 2 siblings, 1 reply; 13+ messages in thread From: Bob Rossi @ 2005-10-09 17:33 UTC (permalink / raw) To: jingzhao.ou, gdb > > On 10/9/05, Bob Rossi <bob@brasko.net> wrote: > > > I think the best idea we've had so far for solving problems like this is > > > to add an option to GDB to have it output GDB/MI data on a file > > > descriptor X. For instance, > > > gdb -i=mi -mi-out-fd=30 > > > and then when you fork/exec GDB you dup the 30 file descriptor so that > > > you can read the output. > > > > > > Eli, do you know if this approach would be portable to windows nativly? > > > I could look into implementing this feature, since it would resolve a > > > *lot* of problems regarding I/O. > > While I think this is a good idea, what other specific problems would > it solve that we haven't solved already? It solves several problems. The user no longer has to create a pty to give to GDB to separate the inferior output and the console output. (CGDB will have to anyways, since it uses the terminal). Some of the target's apparently write to STDOUT/STDERR, and that get's confused with the MI output. Also, thing's like 'shell' and potentially other case's get mixed in with the MI output. Finally, if we have several interpreters going at the same time, we could have them all output to there own descriptor. Bob Rossi ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Separating "shell dir" output from GDB/MI output 2005-10-09 17:33 ` Bob Rossi @ 2005-10-09 20:02 ` Daniel Jacobowitz 2005-10-09 20:19 ` Bob Rossi 0 siblings, 1 reply; 13+ messages in thread From: Daniel Jacobowitz @ 2005-10-09 20:02 UTC (permalink / raw) To: jingzhao.ou, gdb On Sun, Oct 09, 2005 at 01:33:20PM -0400, Bob Rossi wrote: > > > On 10/9/05, Bob Rossi <bob@brasko.net> wrote: > > > > I think the best idea we've had so far for solving problems like this is > > > > to add an option to GDB to have it output GDB/MI data on a file > > > > descriptor X. For instance, > > > > gdb -i=mi -mi-out-fd=30 > > > > and then when you fork/exec GDB you dup the 30 file descriptor so that > > > > you can read the output. > > > > > > > > Eli, do you know if this approach would be portable to windows nativly? > > > > I could look into implementing this feature, since it would resolve a > > > > *lot* of problems regarding I/O. > > > > While I think this is a good idea, what other specific problems would > > it solve that we haven't solved already? > > It solves several problems. The user no longer has to create a pty to > give to GDB to separate the inferior output and the console output. > (CGDB will have to anyways, since it uses the terminal). This one we've already solved, albeit with a bit of extra work on the part of the frontend (and we were all enthusiastic about the solution, too...) > Some of the > target's apparently write to STDOUT/STDERR, and that get's confused with > the MI output. I don't know what you're referring to here. > Also, thing's like 'shell' and potentially other case's > get mixed in with the MI output. Shell's the only one I can think of offhand. > Finally, if we have several > interpreters going at the same time, we could have them all output to > there own descriptor. This is an interesting idea, but I don't think it's an obviously right choice. The CLI frontend wants its own terminal, really. The MI interpreter only needs a pipe. I have use for multiple MI interpreters running at the same time, which will all need their own pipes, but that's not a big deal with the infrastructure we already have. I think wrapping shell's output in MI quoting would be a simpler solution rather than changing the nature of MI/frontend interaction again. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Separating "shell dir" output from GDB/MI output 2005-10-09 20:02 ` Daniel Jacobowitz @ 2005-10-09 20:19 ` Bob Rossi 2005-10-09 20:26 ` Daniel Jacobowitz 0 siblings, 1 reply; 13+ messages in thread From: Bob Rossi @ 2005-10-09 20:19 UTC (permalink / raw) To: jingzhao.ou, gdb On Sun, Oct 09, 2005 at 04:02:48PM -0400, Daniel Jacobowitz wrote: > On Sun, Oct 09, 2005 at 01:33:20PM -0400, Bob Rossi wrote: > > > > On 10/9/05, Bob Rossi <bob@brasko.net> wrote: > > > > > I think the best idea we've had so far for solving problems like this is > > > > > to add an option to GDB to have it output GDB/MI data on a file > > > > > descriptor X. For instance, > > > > > gdb -i=mi -mi-out-fd=30 > > > > > and then when you fork/exec GDB you dup the 30 file descriptor so that > > > > > you can read the output. > > > > > > > > > > Eli, do you know if this approach would be portable to windows nativly? > > > > > I could look into implementing this feature, since it would resolve a > > > > > *lot* of problems regarding I/O. > > > > > > While I think this is a good idea, what other specific problems would > > > it solve that we haven't solved already? > > > > It solves several problems. The user no longer has to create a pty to > > give to GDB to separate the inferior output and the console output. > > (CGDB will have to anyways, since it uses the terminal). > > This one we've already solved, albeit with a bit of extra work on the > part of the frontend (and we were all enthusiastic about the solution, > too...) Sorry, I honestly can't remember what your talking about. What was the solution for this that the front end had to do? Also, don't forget, on windows nativly, the front end *can't* open a PTY. Eli came up with this solution for that problem, http://sources.redhat.com/ml/gdb-patches/2005-08/msg00047.html > > Some of the > > target's apparently write to STDOUT/STDERR, and that get's confused with > > the MI output. > > I don't know what you're referring to here. Oops, sorry. This is in the manual, and apparently is not true, target-stream-output is the output produced by the target program. All the target output is prefixed by `@'. We've had complaints by users that target output is not prefixed with '@'. So, I believe the output from the target can be intermingled with the MI output. > > Also, thing's like 'shell' and potentially other case's > > get mixed in with the MI output. > > Shell's the only one I can think of offhand. Yeah, me too. Darn shell command always break's front ends :( > > Finally, if we have several > > interpreters going at the same time, we could have them all output to > > there own descriptor. > > This is an interesting idea, but I don't think it's an obviously right > choice. The CLI frontend wants its own terminal, really. The MI > interpreter only needs a pipe. I have use for multiple MI interpreters > running at the same time, which will all need their own pipes, but > that's not a big deal with the infrastructure we already have. This is interesting. How would you start up GDB in such a scenario? Say you wanted 2 MI interpreters running. What would you do? > I think wrapping shell's output in MI quoting would be a simpler > solution rather than changing the nature of MI/frontend interaction > again. Yeah, you sound correct on this point. Bob Rossi ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Separating "shell dir" output from GDB/MI output 2005-10-09 20:19 ` Bob Rossi @ 2005-10-09 20:26 ` Daniel Jacobowitz 0 siblings, 0 replies; 13+ messages in thread From: Daniel Jacobowitz @ 2005-10-09 20:26 UTC (permalink / raw) To: jingzhao.ou, gdb On Sun, Oct 09, 2005 at 04:19:23PM -0400, Bob Rossi wrote: > On Sun, Oct 09, 2005 at 04:02:48PM -0400, Daniel Jacobowitz wrote: > > On Sun, Oct 09, 2005 at 01:33:20PM -0400, Bob Rossi wrote: > > > It solves several problems. The user no longer has to create a pty to > > > give to GDB to separate the inferior output and the console output. > > > (CGDB will have to anyways, since it uses the terminal). > > > > This one we've already solved, albeit with a bit of extra work on the > > part of the frontend (and we were all enthusiastic about the solution, > > too...) > > Sorry, I honestly can't remember what your talking about. What was the > solution for this that the front end had to do? Also, don't forget, on > windows nativly, the front end *can't* open a PTY. Eli came up with this > solution for that problem, > http://sources.redhat.com/ml/gdb-patches/2005-08/msg00047.html All I mean is -inferior-set-tty. > > > Some of the > > > target's apparently write to STDOUT/STDERR, and that get's confused with > > > the MI output. > > > > I don't know what you're referring to here. > > Oops, sorry. This is in the manual, and apparently is not true, > target-stream-output is the output produced by the target program. > All the target output is prefixed by `@'. > We've had complaints by users that target output is not prefixed with > '@'. So, I believe the output from the target can be intermingled with > the MI output. As far as I know this was never implemented except maybe for some remote target. > > > Finally, if we have several > > > interpreters going at the same time, we could have them all output to > > > there own descriptor. > > > > This is an interesting idea, but I don't think it's an obviously right > > choice. The CLI frontend wants its own terminal, really. The MI > > interpreter only needs a pipe. I have use for multiple MI interpreters > > running at the same time, which will all need their own pipes, but > > that's not a big deal with the infrastructure we already have. > > This is interesting. How would you start up GDB in such a scenario? Say > you wanted 2 MI interpreters running. What would you do? One of them is for the frontend. The other is for a Guile or Python script being run, either by the user, or in a virtual "thread" in the background watching for some interesting event. Only one of them would have "focus" at a time, i.e. accept input; the others would receive some set of event notifications. That's my theory anyway. I started implementing this, and ran out of steam. I haven't been back to it in a while. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <b5706cf10510091145v5bfa03ben44f62981f174c4a2@mail.gmail.com>]
* Re: Separating "shell dir" output from GDB/MI output [not found] ` <b5706cf10510091145v5bfa03ben44f62981f174c4a2@mail.gmail.com> @ 2005-10-09 18:47 ` jingzhao.ou 2005-10-09 20:04 ` Daniel Jacobowitz 0 siblings, 1 reply; 13+ messages in thread From: jingzhao.ou @ 2005-10-09 18:47 UTC (permalink / raw) To: gdb interpreter-exec can give me what I am looking for. However, its output is mixed with the MI output and will confuse Bob's parser. :-( interpreter-exec console "b main" &"interpreter-exec console \"b main\"\n" Breakpoint 1 at 0x4012e7: file gdbmi_driver.c, line 14. ^done (gdb) It seems that support of multiple file descriptors is a potential solution for such problems. Best regards, Jingzhao On 10/9/05, Daniel Jacobowitz <drow@false.org> wrote: > For now, for a console, you can use -interpreter-exec and get things > more or less right. You can find a lot more about this in the list > archives, e.g. Apple's console-quoted hack. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Separating "shell dir" output from GDB/MI output 2005-10-09 18:47 ` jingzhao.ou @ 2005-10-09 20:04 ` Daniel Jacobowitz 2005-10-10 8:41 ` Re[2]: " Konstantin Karganov 0 siblings, 1 reply; 13+ messages in thread From: Daniel Jacobowitz @ 2005-10-09 20:04 UTC (permalink / raw) To: jingzhao.ou; +Cc: gdb On Sun, Oct 09, 2005 at 11:47:20AM -0700, jingzhao.ou wrote: > interpreter-exec can give me what I am looking for. However, its > output is mixed with the MI output and will confuse Bob's parser. :-( > > interpreter-exec console "b main" > &"interpreter-exec console \"b main\"\n" > Breakpoint 1 at 0x4012e7: file gdbmi_driver.c, line 14. > ^done > (gdb) > > It seems that support of multiple file descriptors is a potential > solution for such problems. IIRC this is exactly what console-quoted was for. Ideally, IMO, we should have the CLI as a true frontend rather than interwoven with gdb. I don't know if that's practical. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re[2]: Separating "shell dir" output from GDB/MI output 2005-10-09 20:04 ` Daniel Jacobowitz @ 2005-10-10 8:41 ` Konstantin Karganov 0 siblings, 0 replies; 13+ messages in thread From: Konstantin Karganov @ 2005-10-10 8:41 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb Hello Daniel, DJ> Ideally, IMO, we should have the CLI as a true frontend rather than DJ> interwoven with gdb. I don't know if that's practical. It would be practical at least from the point of view that GDB developers and GDB-users will stand on the same side of "MI-barricade". It will give a better chance to fix all this misundesrtandings like with phantom "@target-output" feature and refine MI specification and implementation details. -- Best regards, Konstantin mailto:kostik@ispras.ru ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Separating "shell dir" output from GDB/MI output 2005-10-09 17:12 ` Daniel Jacobowitz 2005-10-09 17:33 ` Bob Rossi [not found] ` <b5706cf10510091145v5bfa03ben44f62981f174c4a2@mail.gmail.com> @ 2005-10-15 12:29 ` Eli Zaretskii 2 siblings, 0 replies; 13+ messages in thread From: Eli Zaretskii @ 2005-10-15 12:29 UTC (permalink / raw) To: jingzhao.ou, gdb > Date: Sun, 9 Oct 2005 13:12:26 -0400 > From: Daniel Jacobowitz <drow@false.org> > Cc: gdb@sources.redhat.com > > A simpler and more specific solution for this particular problem would > be to run "shell" through pipes and MI encapsulate its output, to > prevent it from playing with the user's terminal. I think that's a > good idea anyway. I agree. We just need to be careful to use the portable routines, like pexecute or popen/pclose, and then it will work everywhere. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Separating "shell dir" output from GDB/MI output 2005-10-09 12:33 ` Bob Rossi 2005-10-09 17:04 ` jingzhao.ou @ 2005-10-15 12:27 ` Eli Zaretskii 1 sibling, 0 replies; 13+ messages in thread From: Eli Zaretskii @ 2005-10-15 12:27 UTC (permalink / raw) To: jingzhao.ou, gdb > Date: Sun, 9 Oct 2005 08:33:26 -0400 > From: Bob Rossi <bob@brasko.net> > Cc: gdb@sources.redhat.com > > I think the best idea we've had so far for solving problems like this is > to add an option to GDB to have it output GDB/MI data on a file > descriptor X. For instance, > gdb -i=mi -mi-out-fd=30 > and then when you fork/exec GDB you dup the 30 file descriptor so that > you can read the output. > > Eli, do you know if this approach would be portable to windows nativly? dup works on Windows as it does on Posix platforms, but I'm not sure I understand the other details of what you suggest. Could you post a pseudo-code description of what you have in mind? ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2005-10-15 12:29 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-10-09 5:19 Separating "shell dir" output from GDB/MI output jingzhao.ou 2005-10-09 12:33 ` Bob Rossi 2005-10-09 17:04 ` jingzhao.ou 2005-10-09 17:12 ` Daniel Jacobowitz 2005-10-09 17:33 ` Bob Rossi 2005-10-09 20:02 ` Daniel Jacobowitz 2005-10-09 20:19 ` Bob Rossi 2005-10-09 20:26 ` Daniel Jacobowitz [not found] ` <b5706cf10510091145v5bfa03ben44f62981f174c4a2@mail.gmail.com> 2005-10-09 18:47 ` jingzhao.ou 2005-10-09 20:04 ` Daniel Jacobowitz 2005-10-10 8:41 ` Re[2]: " Konstantin Karganov 2005-10-15 12:29 ` Eli Zaretskii 2005-10-15 12:27 ` Eli Zaretskii
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).