From g.watson at computer.org Sat Jul 1 19:56:03 2006 From: g.watson at computer.org (Greg Watson) Date: Thu Jul 12 12:38:51 2007 Subject: [dmi-discuss] DMI Wiki for working on the Spec In-Reply-To: <17573.39864.86568.142375@kahikatea.snap.net.nz> References: <20060605174608.33119.qmail@web51802.mail.yahoo.com> <17540.54203.997827.458306@kahikatea.snap.net.nz> <17573.39864.86568.142375@kahikatea.snap.net.nz> Message-ID: <5F7F99E5-D42B-4761-8EE7-1EA459F41617@computer.org> Great, thanks. I'll take a look at the changes and start working on the wiki again. Greg On Jun 30, 2006, at 3:46 PM, Nick Roberts wrote: > Greg Watson writes: >> Ok. Any idea when that will be? >> >> Greg > > Just to update you, I've now committed all my current changes to > the MI > section of the GDB manual. > > -- > Nick http:// > www.inet.net.nz/~nickrob > > >> On Jun 5, 2006, at 7:00 PM, Nick Roberts wrote: >> >>>> Ok, I've added the syntax sections and the first breakpoint command >>>> section to give you a feel for the layout. Please take a look >>>> and let >>>> me know if it seems ok and you're happy with the formatting. This >>>> wiki seems to have a default paragraph indent that makes the >>>> formatting a bit weird. If anyone knows how to turn it off, please >>>> let me know. >>> >>> The formatting looks good to me. >>> >>>> ... >>>> I'll continue to add sections as I get time. >>> >>> I've recently submitted a patch for the GDB manual which Eli is in >>> the process >>> of reviewing. It might be a good idea to wait for those changes >>> to be >>> incorporated before adding further sections. From susan at smacchia.net Wed Jul 5 12:55:32 2006 From: susan at smacchia.net (Susan Macchia) Date: Thu Jul 12 12:38:51 2007 Subject: [dmi-discuss] Next steps? Message-ID: <20060705195532.67661.qmail@web51809.mail.yahoo.com> Hi all, Once Greg (thanks for volunteering!) has finished working on the wiki incorporating Nick's contributions, what do you think we should do next? I know everyone is pretty busy with thier "other" work, but I don't want to see us lose momentum here. Thanks, Susan _____________________________ Susan Macchia mailto:susan@smacchia.net http://www.smacchia.net _____________________________ From g.watson at computer.org Tue Jul 11 05:57:08 2006 From: g.watson at computer.org (Greg Watson) Date: Thu Jul 12 12:38:51 2007 Subject: [dmi-discuss] Next steps? In-Reply-To: <20060705195532.67661.qmail@web51809.mail.yahoo.com> References: <20060705195532.67661.qmail@web51809.mail.yahoo.com> Message-ID: <00A4772D-8AD6-4528-9053-E9825A3B2352@computer.org> Once we get the documentation up on the wiki (as soon as I can find some spare time!), we need to: 1. determine if each command is implemented in gdb 2. update the document to provide a detailed description of each command's output 3. agree that each command should become part of the spec, including deciding the fate of unimplemented commands (if any) 4. discuss and agree on changes to existing commands, and new commands and functionality that should be added Greg On Jul 5, 2006, at 1:55 PM, Susan Macchia wrote: > Hi all, > > Once Greg (thanks for volunteering!) has finished working on the wiki > incorporating Nick's contributions, what do you think we should do > next? > > I know everyone is pretty busy with thier "other" work, but I don't > want to see > us lose momentum here. > > Thanks, > Susan > > _____________________________ > Susan Macchia > mailto:susan@smacchia.net > http://www.smacchia.net > _____________________________ > > _______________________________________________ > dmi-discuss mailing list > dmi-discuss@lists.freestandards.org > http://lists.freestandards.org/mailman/listinfo/dmi-discuss From nickrob at snap.net.nz Sat Jul 15 16:11:23 2006 From: nickrob at snap.net.nz (Nick Roberts) Date: Thu Jul 12 12:38:51 2007 Subject: [dmi-discuss] MI: event notification In-Reply-To: <0DEBAC0A-BF26-414A-ABE6-DFE5105A684C@apple.com> References: <17560.40409.61785.698765@kahikatea.snap.net.nz> <20060621013437.GA17956@nevyn.them.org> <17560.44395.508930.351917@kahikatea.snap.net.nz> <20060621023258.GA19167@nevyn.them.org> <0DEBAC0A-BF26-414A-ABE6-DFE5105A684C@apple.com> Message-ID: <17593.30235.462941.279388@kahikatea.snap.net.nz> Jim Ingham writes: > We don't do what Nick's suggesting. We do do something similar for > shared library notifications - we emit async notifications for shared > library load events from gdb so Xcode doesn't have to stop on solib > events & get the shlig list. Similarly if a shared library load > causes a pended breakpoint to get loaded we tell about that as well. > > But we don't do anything for stack changes. Note, except in the case > where you have gotten stuck in some kind of pathological recursion, I > would be surprised if it's consing up the stack list for the MI that > takes a significant portion of the time, so I'm not sure this example > isn't a false optimization. But anyway, we don't do that. I thought previous discussion (Vladimir Prus) suggested that -stack-list-argments, at least, was time consuming. If the stack is 1000's of frames deep, it must surely be time comsuming to compute and re-display it at every step. The depth can be restricted but I think you have said that the first ones take are the hardest to compute. In any case, we need to be scientific about it, so I propose to add a time field to the MI output. ISTR that Apple's MI already has this. Are you planning to include this (or the async notifications for shared librarys) in the DMI specification? I would like to avoid unnecessary duplication of effort. -- Nick http://www.inet.net.nz/~nickrob From jingham at apple.com Mon Jul 17 14:11:03 2006 From: jingham at apple.com (Jim Ingham) Date: Thu Jul 12 12:38:51 2007 Subject: [dmi-discuss] MI: event notification In-Reply-To: <17593.30235.462941.279388@kahikatea.snap.net.nz> References: <17560.40409.61785.698765@kahikatea.snap.net.nz> <20060621013437.GA17956@nevyn.them.org> <17560.44395.508930.351917@kahikatea.snap.net.nz> <20060621023258.GA19167@nevyn.them.org> <0DEBAC0A-BF26-414A-ABE6-DFE5105A684C@apple.com> <17593.30235.462941.279388@kahikatea.snap.net.nz> Message-ID: On Jul 15, 2006, at 4:11 PM, Nick Roberts wrote: > Jim Ingham writes: >> We don't do what Nick's suggesting. We do do something similar for >> shared library notifications - we emit async notifications for shared >> library load events from gdb so Xcode doesn't have to stop on solib >> events & get the shlig list. Similarly if a shared library load >> causes a pended breakpoint to get loaded we tell about that as well. >> >> But we don't do anything for stack changes. Note, except in the case >> where you have gotten stuck in some kind of pathological recursion, I >> would be surprised if it's consing up the stack list for the MI that >> takes a significant portion of the time, so I'm not sure this example >> isn't a false optimization. But anyway, we don't do that. > > I thought previous discussion (Vladimir Prus) suggested that > -stack-list-argments, at least, was time consuming. If the stack is > 1000's of > frames deep, it must surely be time comsuming to compute and re- > display it at > every step. The depth can be restricted but I think you have said > that the > first ones take are the hardest to compute. We have a simple backtracer that just follows the frame pointer, and doesn't do any of the fancy unwinding of registers, etc. When I get it to print roughly the same information as the ordinary -stack-list- frames it's ~10 times faster than -stack-list-frames. So I'm pretty sure most of the time in -stack-list-frames is doing real work computing the backtrace, and only a small portion is consing up the output. To tell whether the stack has changed or not you have to do the backtrace (even if you don't report it.) So my guess is this change wouldn't save very much time. The shared-libraries one was a win because we got the UI out of the process of stopping & starting again on shared library hit. For > > In any case, we need to be scientific about it, so I propose to add > a time > field to the MI output. ISTR that Apple's MI already has this. Are > you > planning to include this (or the async notifications for shared > librarys) in > the DMI specification? I would like to avoid unnecessary > duplication of > effort. Dunno if the timing belongs in the spec, since it's more of a diagnostic thing. But it is really handy to have... The shared library notification is really useful and probably should go in. Jim From nickrob at snap.net.nz Mon Jul 17 14:58:53 2006 From: nickrob at snap.net.nz (Nick Roberts) Date: Thu Jul 12 12:38:51 2007 Subject: [dmi-discuss] MI: event notification In-Reply-To: References: <17560.40409.61785.698765@kahikatea.snap.net.nz> <20060621013437.GA17956@nevyn.them.org> <17560.44395.508930.351917@kahikatea.snap.net.nz> <20060621023258.GA19167@nevyn.them.org> <0DEBAC0A-BF26-414A-ABE6-DFE5105A684C@apple.com> <17593.30235.462941.279388@kahikatea.snap.net.nz> Message-ID: <17596.2077.682837.126332@kahikatea.snap.net.nz> > > In any case, we need to be scientific about it, so I propose to add a > > time field to the MI output. ISTR that Apple's MI already has this. Are > > you planning to include this (or the async notifications for shared > > librarys) in the DMI specification? I would like to avoid unnecessary > > duplication of effort. > > Dunno if the timing belongs in the spec, since it's more of a > diagnostic thing. But it is really handy to have... The shared > library notification is really useful and probably should go in. If timing is not part of the DMI spec, which sounds reasonable, then I think that should be documented too. -- Nick http://www.inet.net.nz/~nickrob From g.watson at computer.org Mon Jul 17 15:11:57 2006 From: g.watson at computer.org (Greg Watson) Date: Thu Jul 12 12:38:51 2007 Subject: [dmi-discuss] wiki document status Message-ID: Ok, I've uploaded the main MI documentation. Please take a look and give me your feedback. I made a few minor changes in the translation from the GDB document, mainly removing GDB specific sections and GDB examples. Here's a suggestion for the things that need to happen now. Please add/remove as you see fit. 1. Change references to 'GDB' to 'debugger' and 'GDB/MI' to 'DMI' and fix up wording if necessary. 2. Check the document for consistency. For example, there are some places where quotes are used, but not in other places. 3. Test each command in gdb to determine (a) that it is implemented, and (b) the result output (this may involve checking the source code as well). 4. Update the 'Result' section for each command with this result syntax. 5. Review each commands that have 'gdb' in the command string and agree if the commands should be changed to something non specific. 6. Review each command for compatibility with other debugger implementation; determine and agree on what changes need to be made. 7. Review and agree on commands that should be removed, and other changes to the current specification. We should probably seek volunteers for each of these tasks and have a table on the wiki showing who is doing what. (I'm happy to do 1, 2 and 4, but I think other people will need to be involved in the remaining activities.) At some point when we are comfortable that the document is close to a specification, we should 'freeze' changes and give it a version number. At this stage we should probably adopt a more formal process for future changes. Regards, Greg