* Re: vast numbers of unimplemented MI commands. [not found] <1063899004.27567.ezmlm@sources.redhat.com> @ 2003-09-18 17:10 ` Jim Ingham 2003-09-19 14:50 ` Alain Magloire 0 siblings, 1 reply; 11+ messages in thread From: Jim Ingham @ 2003-09-18 17:10 UTC (permalink / raw) To: gdb On Sep 18, 2003, at 8:30 AM, gdb-digest-help@sources.redhat.com wrote: > > >> >> Hi, >> >> I guess this seems ok, I just hate to see stuff like this. >> >> But if you can come up with a clean Interface(set of methods) of >> what you need we could work things and put it in the CDI and >> implement >> it in the GDB/MI plugin. The annoying thing is that GDB/MI does >> not >> have any "mi" command for this, so we will have to send "cli" >> command >> and do weird parsing on the output. >> >> from the eclipse mailing lists. Seeing this makes me think that the >> whole community is not understanding that we need to have clean >> interfaces between GDB and the front ends. >> > > Amen to that!! > >> Developers that find a "missing hole" in GDB, don't seem to have the >> desire to fix the hole when they can easily find a work around. >> IMO, most developers don't have enough time to fix there own >> front end and then go fix the debugger there integrating with. > > I hear you !!! 8-) > >> I think GDB should support a proper MI interface for front ends, and >> thats the only way front ends should be able to communicate with it. >> Adding the -interpreter console was probably the main cause in >> allowing >> front ends to cheat there way past the MI interface. I don't think that is right. You could always issue console commands straight to the mi, THAT is the real way to cheat (and I agree that should be closed off). The console interpreter (and -interpreter-exec console) fulfills a very useful purpose: satisfying folks who like a console interface to gdb as well as the GUI. We would probably get assassinated right quick if we were to try to take this out of Xcode (used to be Project Builder - another Marketing person earns their salary!) . Note that we have had to fix up a few things in the MI as we have gone along with Xcode, and most of those fixes are in the Apple sources not in the main FSF repository. We are short-staffed for what we need to do here, which sort of explains why we haven't gotten to submitting our sources back to the FSF - experience has shown that to be very time consuming. But you can get the Apple sources from the Apple Darwin site, or from the opendarwin site. If you are serious about using the MI it might be worth your while to have a look here, since Xcode is the only fairly mature GUI the uses the MI... >> > > Agreed, but not for the same reasons. We do not use the > "-interpreter-exec console" > because it turns out to be useless. The first attempt was to satisfy > the CLI users > within the IDE, so a prompt was given. But the problem is to > synchronize the IDE, > let see a scenario, the "show": > > - scenario 1 (show): > > # gdb -i mi hello > ... > (gdb) > show auto-solib > &"show auto-solib\n" > ^done,value="on" > (gdb) > > The problem here, and with many other commands, is that the > information is return in MI jargon > only, so the user will not see it. To do this correctly we would > need a cli interpreter > that will pretty print the output of any commands(no fun job, knowin > the annoying cli syntax of gdb). > I don't understand this comment. This is exactly what -interpreter-exec console is for. If the user issues this sort of console command, you just echo back whatever it sends to your console window. You can also annotate if they do anything of other interest to the GUI (proceeding the inferior, setting breakpoints, etc...) Note that to make parsing the output from gdb, I added a "console-quoted" interpreter that sends stuff back in the cli pretty-printing, but the output strings are packaged up in MI format. So you get something like: -interpreter-exec console-quoted "info func" ~"All defined functions:\n" ~"\nFile " ~"/SourceCache/Csu/Csu-46/crt.c:\n" ~"void _start(int, char **, char **);\n" ~"static void _call_mod_init_funcs(void);\n" ... ^done,time={wallclock="1.83584",user="1.02000",system="0.11000",start="1 063903591.475599",end="1063903593.311440"} (gdb) This means that if the response from a command happens to start with ^done or something like that, you won't get confused... I still have some cleanup to do on this, because there are various places (like the show command) where the command ignores the uiout and prints straight to gdbstdout (grrr....) But this makes it pretty easy to handle this sort of thing. > > - scenario 2 (show/next): > > The problem is reverse when doing -interpreter-exec, the information > not is not in MI, > this is illustrate when doing a "next" > > (gdb) > -interpreter-exec console next > ~"41\t\tchar array[2][2] = { 'a', 'b', 'c'};\n" > ^done > (gdb) > > The front-end fall out of step with gdb and no longer has relevant > information. > However doing CLI without -interpreter-exec is good. > > (gdb) > next > &"next\n" > ^done,reason="end-stepping-range",thread- > id="0",frame={addr="0x0804846e",func="main",args=[{name="argc",value="1 > "},{name="argv",value="0xbfffeb54"}],file="hello.c",line="40"} > (gdb) > > The front-end can keep up. This is just a hole in the interpreter-exec console implementation. We tarted this up a bit on our end, so you get: -interpreter-exec console-quoted next ^stepping ^running (gdb) *stopped,time={wallclock="0.01305",user="0.00000",system="0.02000",start ="1063903739.568366",end="1063903739.581413"},reason="end-stepping- range",thread-id="1" I forget why the GUI guys wanted the ^stepping as well as the ^running, for regularity it would probably be better to leave that out. But with this modification, it is very easy to keep the GUI in sync with the CLI. The Xcode console interpreter actually works pretty well, and very seldom gets out of sync with the GUI. > >> The problem is, every *real* world front end to GDB is doomed to end >> up >> using a mix of MI commands and CLI commands. If GDB is ever released >> in such a way that the CLI output is changed, all existing front ends >> will break. Including the ones that use MI. This has not been our experience. Xcode doesn't use any CLI commands, provided you don't consider "-interpreter-exec" a console command. It took some work on our part to get this all going, but it is very achievable. >> >> What is the best solution? ... >> > > Good question. Although I like to complain 8-) > The move toward MI is a good one, it is much cleaner, kudos to gdb > folks. We have had pretty good success with the MI so far... Jim -- Jim Ingham jingham@apple.com Developer Tools Apple Computer ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: vast numbers of unimplemented MI commands. 2003-09-18 17:10 ` vast numbers of unimplemented MI commands Jim Ingham @ 2003-09-19 14:50 ` Alain Magloire 2003-09-19 14:53 ` open watcom y2bismil 0 siblings, 1 reply; 11+ messages in thread From: Alain Magloire @ 2003-09-19 14:50 UTC (permalink / raw) To: Jim Ingham; +Cc: gdb [some lines deleted] .... > I don't think that is right. You could always issue console commands > straight to the mi, THAT is the real way to cheat (and I agree that > should be closed off). The console interpreter (and -interpreter-exec > console) fulfills a very useful purpose: satisfying folks who like a > console interface to gdb as well as the GUI. We would probably get > assassinated right quick if we were to try to take this out of Xcode > (used to be Project Builder - another Marketing person earns their > salary!) . > > Note that we have had to fix up a few things in the MI as we have gone > along with Xcode, and most of those fixes are in the Apple sources not > in the main FSF repository. We are short-staffed for what we need to And for the fixes ... thank you !!! > do here, which sort of explains why we haven't gotten to submitting our > sources back to the FSF - experience has shown that to be very time > consuming. But you can get the Apple sources from the Apple Darwin > site, or from the opendarwin site. If you are serious about using the > MI it might be worth your while to have a look here, since Xcode is the > only fairly mature GUI the uses the MI... > I disagree 8-). There are a few that uses MI and do a good job at it. This is not saying Xcode is not a great product of course 8-) I do not have a Mac to try it, but any URL handy with good snapshots? or just docs on Xcode ? [...] > I don't understand this comment. This is exactly what > -interpreter-exec console is for. If the user issues this sort of > console command, you just echo back whatever it sends to your console > window. You can also annotate if they do anything of other interest to > the GUI (proceeding the inferior, setting breakpoints, etc...) Note > that to make parsing the output from gdb, I added a "console-quoted" > interpreter that sends stuff back in the cli pretty-printing, but the > output strings are packaged up in MI format. So you get something > like: > > -interpreter-exec console-quoted "info func" > ~"All defined functions:\n" > ~"\nFile " > ~"/SourceCache/Csu/Csu-46/crt.c:\n" > ~"void _start(int, char **, char **);\n" > ~"static void _call_mod_init_funcs(void);\n" > ... > ^done,time={wallclock="1.83584",user="1.02000",system="0.11000",start="1 > 063903591.475599",end="1063903593.311440"} > (gdb) > > > This means that if the response from a command happens to start with > ^done or something like that, you won't get confused... > Yes this is the answer to our prayers. "-interpreter-exec console" does not do anything for us since we can not use it to sync the UI from the user input. However "-interpreter-exec console-quoted", at least, how you describe it is what we want. > I still have some cleanup to do on this, because there are various > places (like the show command) where the command ignores the uiout and > prints straight to gdbstdout (grrr....) But this makes it pretty easy > to handle this sort of thing. > 8-) > [...] > This is just a hole in the interpreter-exec console implementation. We > tarted this up a bit on our end, so you get: > > -interpreter-exec console-quoted next > ^stepping > ^running > (gdb) > *stopped,time={wallclock="0.01305",user="0.00000",system="0.02000",start > ="1063903739.568366",end="1063903739.581413"},reason="end-stepping- > range",thread-id="1" > Yes, Yes , Yes ! Now __This__ is usefull. > I forget why the GUI guys wanted the ^stepping as well as the ^running, > for regularity it would probably be better to leave that out. But with > I can guess: ^stepping and ^running are vital for the IDE to maintain its state without them "console-quoted" is as useless as "-interpreter-exec console". There is a difference between "next" and "continue"(for the IDE) and the ^running is if the next statement is blocking, the IDE will know that it is running. > this modification, it is very easy to keep the GUI in sync with the > CLI. The Xcode console interpreter actually works pretty well, and > very seldom gets out of sync with the GUI. > In any case ... very nice improvements. [...] > This has not been our experience. Xcode doesn't use any CLI commands, > provided you don't consider "-interpreter-exec" a console command. It > took some work on our part to get this all going, but it is very > achievable. > Well then how do you deal with shared libraries ? How do you do deferred breakpoints? how do you load a shared library symbol ? How do you get the signal handlers? How do you set the handle for a signal ? etc, etc ... There are currently no MI counterparts ... at least in the FSF version. And the console prompt is a problem that "-interpreter-exec console" does not solve, .. but looking forward for "-interpreter-exec console-quoted". ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: open watcom 2003-09-19 14:50 ` Alain Magloire @ 2003-09-19 14:53 ` y2bismil 0 siblings, 0 replies; 11+ messages in thread From: y2bismil @ 2003-09-19 14:53 UTC (permalink / raw) To: gdb Hi Jim Blandy, Here is the output of the object dump *********************************************** C:\src\watcom>objdump -h test2.exe test2.exe: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 AUTO 00008000 00401000 00401000 00000400 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .idata 00000600 00409000 00409000 00008400 2**2 CONTENTS, ALLOC, LOAD, DATA 2 DGROUP 00001200 0040a000 0040a000 00008a00 2**2 CONTENTS, ALLOC, LOAD, DATA 3 .bss 00000a00 0040c000 0040c000 00000000 2**4 ALLOC 4 .reloc 00000800 0040d000 0040d000 00009c00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA, DEBUGGING *********************************************** Yamin ---------------------------------------- This mail sent through www.mywaterloo.ca ^ permalink raw reply [flat|nested] 11+ messages in thread
* open watcom @ 2003-09-18 20:21 y2bismil 0 siblings, 0 replies; 11+ messages in thread From: y2bismil @ 2003-09-18 20:21 UTC (permalink / raw) To: gdb Hey guys, We're exploring a new development environment here, and as part of the migration process, I was wondering if its possible to debug code genered by the open watcom compiler using gdb. I've tried unsuccessfully setting the debugging in watcom to: watcom, codeview, and dwarf, but to no avail. Does anyone know the location of a list of supported debug format by gdb? thanks all, Yamin ---------------------------------------- This mail sent through www.mywaterloo.ca ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: open watcom
@ 2003-09-18 20:25 Michael Elizabeth Chastain
2003-09-18 20:29 ` Joel Brobecker
2003-09-18 20:34 ` y2bismil
0 siblings, 2 replies; 11+ messages in thread
From: Michael Elizabeth Chastain @ 2003-09-18 20:25 UTC (permalink / raw)
To: gdb, y2bismil
> Does anyone know the location of a list of supported debug format by gdb?
dwarf 1, dwarf 1+
dwarf 2
stabs, stabs+
coff, xcoff, xcoff+
mdebug
Also, I'm not sure whether "hp" is an object code format or a debug
format.
Michael C
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: open watcom 2003-09-18 20:25 Michael Elizabeth Chastain @ 2003-09-18 20:29 ` Joel Brobecker 2003-09-18 20:34 ` y2bismil 1 sibling, 0 replies; 11+ messages in thread From: Joel Brobecker @ 2003-09-18 20:29 UTC (permalink / raw) To: Michael Elizabeth Chastain; +Cc: gdb, y2bismil > Also, I'm not sure whether "hp" is an object code format or a debug > format. HP32 uses SOM (object format). The Debug format used is then stabs. HP64 uses ELF, in which case you have the choice between stabs or dwarf2. -- Joel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: open watcom 2003-09-18 20:25 Michael Elizabeth Chastain 2003-09-18 20:29 ` Joel Brobecker @ 2003-09-18 20:34 ` y2bismil 1 sibling, 0 replies; 11+ messages in thread From: y2bismil @ 2003-09-18 20:34 UTC (permalink / raw) To: gdb Thanks Michael, open watcom does support dwarf1, and so I tried that, but still nothing. GDB just keeps saying it can't find any debug information. Shuold gdb automatically detect the debug type, or is there an option? Thanks Quoting Michael Elizabeth Chastain <mec@shout.net>: > > Does anyone know the location of a list of supported debug format by gdb? > > dwarf 1, dwarf 1+ > dwarf 2 > stabs, stabs+ > coff, xcoff, xcoff+ > mdebug > > Also, I'm not sure whether "hp" is an object code format or a debug > format. > > Michael C > Quoting Michael Elizabeth Chastain <mec@shout.net>: > > Does anyone know the location of a list of supported debug format by gdb? > > dwarf 1, dwarf 1+ > dwarf 2 > stabs, stabs+ > coff, xcoff, xcoff+ > mdebug > > Also, I'm not sure whether "hp" is an object code format or a debug > format. > > Michael C > ---------------------------------------- This mail sent through www.mywaterloo.ca ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: open watcom @ 2003-09-18 21:11 Michael Elizabeth Chastain 2003-09-18 21:20 ` y2bismil 0 siblings, 1 reply; 11+ messages in thread From: Michael Elizabeth Chastain @ 2003-09-18 21:11 UTC (permalink / raw) To: gdb, y2bismil Check the switches for open watcom. It's likely that you need to specify debug switches both at compile time *and* link time when building your program. gdb automatically detects debug type. I know that other people have used dwarf 1, and I ran the gdb test suite on it earlier this year. So I know that gdb does automatically detect and use dwarf-1 debug information with gcc -gdwarf. Michael C ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: open watcom 2003-09-18 21:11 Michael Elizabeth Chastain @ 2003-09-18 21:20 ` y2bismil 2003-09-18 22:44 ` Jim Blandy 0 siblings, 1 reply; 11+ messages in thread From: y2bismil @ 2003-09-18 21:20 UTC (permalink / raw) To: gdb Yep, I've rechecked my options, and in both the compile and link time, I have the debug swtich to use DWARF. Yamin Quoting Michael Elizabeth Chastain <mec@shout.net>: > Check the switches for open watcom. It's likely that you need to > specify debug switches both at compile time *and* link time when > building your program. > > gdb automatically detects debug type. > > I know that other people have used dwarf 1, and I ran the gdb test > suite on it earlier this year. So I know that gdb does automatically > detect and use dwarf-1 debug information with gcc -gdwarf. > > Michael C > ---------------------------------------- This mail sent through www.mywaterloo.ca ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: open watcom 2003-09-18 21:20 ` y2bismil @ 2003-09-18 22:44 ` Jim Blandy 0 siblings, 0 replies; 11+ messages in thread From: Jim Blandy @ 2003-09-18 22:44 UTC (permalink / raw) To: y2bismil; +Cc: gdb y2bismil@engmail.uwaterloo.ca writes: > Yep, I've rechecked my options, and in both the compile and link time, I have > the debug swtich to use DWARF. Can you post the output produced by running 'objdump -h' on your executable file? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: open watcom @ 2003-09-18 21:54 Michael Elizabeth Chastain 0 siblings, 0 replies; 11+ messages in thread From: Michael Elizabeth Chastain @ 2003-09-18 21:54 UTC (permalink / raw) To: gdb, y2bismil Well, I think you are stuck: gdb doesn't support open watcom. open watcom has no documentation that I could find about gdb. google "open watcom gdb" did not find anybody talking about using open watcom and gdb. You could ask on an open watcom list if open watcom interacts with gdb, and if anyone has actually used that combination. I suggest that you check out the debugger that comes with Open Watcom. I will file an enhancement request against gdb to add support for open watcom. It is a lot of work to add support for a new compiler; someone would have to volunteer to do this work. Open Watcom is licensed under the Sybase Open Watcom Public License, which is an OSI-approved open source license. So I think it would be reasonable to consider adding support for this compiler, if a volunteer steps up. Michael C ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2003-09-19 14:53 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1063899004.27567.ezmlm@sources.redhat.com> 2003-09-18 17:10 ` vast numbers of unimplemented MI commands Jim Ingham 2003-09-19 14:50 ` Alain Magloire 2003-09-19 14:53 ` open watcom y2bismil 2003-09-18 20:21 y2bismil 2003-09-18 20:25 Michael Elizabeth Chastain 2003-09-18 20:29 ` Joel Brobecker 2003-09-18 20:34 ` y2bismil 2003-09-18 21:11 Michael Elizabeth Chastain 2003-09-18 21:20 ` y2bismil 2003-09-18 22:44 ` Jim Blandy 2003-09-18 21:54 Michael Elizabeth Chastain
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).