From alain at qnx.com Thu May 4 08:42:02 2006 From: alain at qnx.com (Alain Magloire) Date: Thu Jul 12 12:38:51 2007 Subject: [dmi-discuss] MI symbol query commands specification thoughts Message-ID: <3518719F06577C4F85DA618E3C37AB910521316B@nimbus.ott.qnx.com> > > > > On Apr18, 2006, at 6:10:46 PM, Jim Ingham wrote: > > > > >On Apr 18, 2006, at 2:46 PM, Daniel Jacobowitz wrote: > > > > > >> On Tue, Apr 18, 2006 at 08:52:13AM -0700, Jim Ingham wrote: > > >>> I meant at the shared library level - like what would be returned > > >>> by - > > >>> file-list-shared-libraries. > > >> > > >> (gdb) interpreter-exec mi "-file-list-shared-libraries" > > >> ^error,msg="Undefined mi command: file-list-shared-libraries > > >> (missing implementation)" > > >> > > >> Am I to guess that you've filled this in? :-) > > > > > >Actually no, we deliver the shared library info through added & > > >updated asynchronous messages, e.g. > > > > > >=shlibs-added,shlib-info= > > >[num="2",name="libmathCommon.A.dylib",kind="-",dyld- > > >addr="0x90213000",reason="dyld",requested-state="E",state="E",path="/ > > >usr/lib/system/libmathCommon.A.dylib",description="/usr/lib/system/ > > >libmathCommon.A.dylib",loaded_addr="0x90213000",slide="0x0",prefix=""] > > > > > >etc. The Xcode guys asked us to do it this way, I don't remember why > > >now, and they never asked us for -file-list-shared-libraries. I was > > >just using that as a for-instance :-) > > [resending] I like it 8-), this would get rid of the polling we are currently doing in the Eclipse/CDT/Debug, awful hacks, doing: "info thread" and "info shared" can be costly on some architectures. Thread creations and library loading notifications should be done with async and doing this will allow the front end to look much more responsive. The format you are showing seems a little verbose, are all the fields necessary? Do you have async responses for thread creation/destruction? Do you have something similar for lib unloaded? =shlibs-removed, .... Maybe we can use it as the basis to extend DMI From alain at qnx.com Mon May 8 09:02:54 2006 From: alain at qnx.com (Alain Magloire) Date: Thu Jul 12 12:38:51 2007 Subject: [dmi-discuss] RE: asynchronous MI output commands Message-ID: <3518719F06577C4F85DA618E3C37AB91052138E1@nimbus.ott.qnx.com> > Daniel Jacobowitz > > On Sun, May 07, 2006 at 08:29:35PM -0400, Bob Rossi wrote: .... > > Yes, I agree, if I knew the MI input command, I could use that to > > determine what type of command I was looking at. If I won't be allowed > > to add the command to the output record, then this is what I will do. > > > > However, I would like to be able to do this with out knowing the MI > input > > command. First, it makes the code more modular that takes the MI output > > and turns it into something meaningful. Second, it's easy to gather a > > bunch of MI output commands from the test suite or from FE user's with > > FE problem, and parse just that output. Third, it validates that what > > the user requested is what the user is getting. It is possible that the > > FE and GDB could get mixed up I'm assumming. > > You're trying to turn a response into a meaningful message without > knowing what it's a response to. I just don't see the benefit of this; > although people keep telling me it's harder than I understand, I > still haven't seen an example that I consider plausible. > Right, 8-). I think folks writing front-ends go naturally in that direction because it is simply easier and it decouples the code so we do not need to synchronize between commands and response. Basically you can have one thread posting commands and another parsing response. But that said, I have to agree with you, it is not a necessity and in reality we will need to associate response with a command or a caller i.e. to update a tree view or whatever viewer that initiate the sequence. > It's easy to gather output from e.g. the testsuite, true. But it's > equally easy to record the commands - just about everything is going to > go through mi_gdb_test, or you could even write a proxy between the > testsuite and GDB which logged, or add the logging to GDB directly. I > know Eclipse's MI protocol log includes the commands it sent. > > Your third point is valid, but does not seem particularly important to > me. If it's wrong, it's wrong. GDB would just have to stitch the > command name on at the end right before outputing the result record, > so that wouldn't gain you much at all. > MI offers a simple way to associate response and commands, by tagging the commands the ^done will come back with the associated tag. > > Anyways, Daniel, thanks for taking time out of your busy schedule to > > think about this issue. If you simply don't want something like this in > > MI right now, I'll find a way to match the input with the output. > > I'm not supreme dictator of this stuff; someone else is welcome to step > in and disagree. I'm just not convinced, either. > OOB messages are important and are not necessarily associated with a command, they may be side effects of something the front-end did not initiate, for example loading libraries, creating threads etc .. As you decoupling completely responses form command, may look like a good idea only on the surface. From jeff at licquia.org Mon May 8 10:04:05 2006 From: jeff at licquia.org (Jeff Licquia) Date: Thu Jul 12 12:38:51 2007 Subject: [dmi-discuss] Version Control discussion Message-ID: <1147107845.23568.205.camel@localhost.localdomain> I have been remiss in making proposals and discussing a new version control system for the FSG, but doing so in lsb-futures without notifying the other workgroups. Short summary: I originally proposed using Subversion, but others in the group said they'd rather use a distributed version control system. Ted T'so proposed Mercurial as the system. Nick Stoughton proposed using Perforce. I have just today written proposed plans for using Subversion and Mercurial. Some archived posts of interest: http://lists.freestandards.org/pipermail/lsb-futures/2006-May/002055.html http://lists.freestandards.org/pipermail/lsb-futures/2006-May/002056.html http://lists.freestandards.org/pipermail/lsb-futures/2006-May/002064.html http://lists.freestandards.org/pipermail/lsb-futures/2006-May/002070.html http://lists.freestandards.org/pipermail/lsb-futures/2006-May/002071.html Please send feedback to lsb-futures, or to me directly (and I will ensure it gets heard). From drow at false.org Wed May 24 09:07:56 2006 From: drow at false.org (Daniel Jacobowitz) Date: Thu Jul 12 12:38:51 2007 Subject: [dmi-discuss] Licensing information from the GDB manual Message-ID: <20060524160756.GA31211@nevyn.them.org> One thing we talked about in today's meeting was the license/copyright issues; I promised to fish out the text of the Invariant Sections. If you take a look at the top of gdb/doc/gdb.texi in any recent copy of GDB, the license terms are there. This is the particularly interesting bit: Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being ``Free Software'' and ``Free Software Needs Free Documentation'', with the Front-Cover Texts being ``A GNU Manual,'' and with the Back-Cover Texts as in (a) below. (a) The Free Software Foundation's Back-Cover Text is: ``You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development.'' Those two sections make up a couple of pages (~ 106 lines in Info). >From the FSG website's documentation policy, it looks like this may be a problem if we want them to publish it - they actually want copyright assigned to FSG, and they dislike invariant sections. -- Daniel Jacobowitz CodeSourcery