* Multiple breakpoint locations @ 2007-11-13 19:15 Nick Roberts 2007-11-13 19:28 ` Vladimir Prus ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: Nick Roberts @ 2007-11-13 19:15 UTC (permalink / raw) To: gdb The new code for breakpoints with multiple locations looks very good and addresses a common complaint about GDB. I have a couple of points and apologise if they have already been discussed. Folowing the example in the manual: Num Type Disp Enb Address What 1 breakpoint keep y <MULTIPLE> stop only if i==1 breakpoint already hit 1 time 1.1 y 0x080486a2 in void foo<int>() at t.cc:8 1.2 y 0x080486ca in void foo<double>() at t.cc:8 1) I can enable/disable 1.1 and 1.2 but not delete them: (gdb) dis 1.1 Num Type Disp Enb Address What 1 breakpoint keep y <MULTIPLE> stop only if i==1 breakpoint already hit 1 time 1.1 n 0x080486a2 in void foo<int>() at t.cc:8 1.2 y 0x080486ca in void foo<double>() at t.cc:8 (gdb) d 1.1 warning: bad breakpoint number at or near '1.1' 2) I can enable/disable 1 and this appears to enable/disable all the locations. Perhap this could be documented in the manual. 3) I created this breakpoint by specifying the line but if I do: b foo<int>() or any variant I can think of, I just get a pending breakpoint as GDB doesn't recognise the location. Can such locations be specified on the command line by name? -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-13 19:15 Multiple breakpoint locations Nick Roberts @ 2007-11-13 19:28 ` Vladimir Prus 2007-11-13 19:59 ` Daniel Jacobowitz ` (2 more replies) 2007-11-17 11:55 ` Eli Zaretskii 2007-11-17 12:07 ` Eli Zaretskii 2 siblings, 3 replies; 31+ messages in thread From: Vladimir Prus @ 2007-11-13 19:28 UTC (permalink / raw) To: gdb Nick Roberts wrote: > > The new code for breakpoints with multiple locations looks very good and > addresses a common complaint about GDB. I have a couple of points and > apologise if they have already been discussed. > > Folowing the example in the manual: > > Num Type Disp Enb Address What > 1 breakpoint keep y <MULTIPLE> > stop only if i==1 > breakpoint already hit 1 time > 1.1 y 0x080486a2 in void foo<int>() at > t.cc:8 > 1.2 y 0x080486ca in void foo<double>() at > t.cc:8 > > > 1) I can enable/disable 1.1 and 1.2 but not delete them: > > (gdb) dis 1.1 > > Num Type Disp Enb Address What > 1 breakpoint keep y <MULTIPLE> > stop only if i==1 > breakpoint already hit 1 time > 1.1 n 0x080486a2 in void foo<int>() at > t.cc:8 > 1.2 y 0x080486ca in void foo<double>() at > t.cc:8 > > (gdb) d 1.1 > warning: bad breakpoint number at or near '1.1' Well, you can't really delete a location -- if breakpoint expression corresponds to 20 addresses, that's the way it is -- you cannot delete some of those addresses from the program ;-) > 2) I can enable/disable 1 and this appears to enable/disable all the > locations. > Perhap this could be documented in the manual. Well yes. Patches welcome ;-) > 3) I created this breakpoint by specifying the line but if I do: > > b foo<int>() > > or any variant I can think of, I just get a pending breakpoint as GDB > doesn't recognise the location. Can such locations be specified on the > command line by name? Does b 'void foo<int>()' work better? - Volodya ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-13 19:28 ` Vladimir Prus @ 2007-11-13 19:59 ` Daniel Jacobowitz 2007-11-13 20:09 ` Nick Roberts 2007-11-13 22:18 ` Eli Zaretskii 2 siblings, 0 replies; 31+ messages in thread From: Daniel Jacobowitz @ 2007-11-13 19:59 UTC (permalink / raw) To: Vladimir Prus; +Cc: gdb On Tue, Nov 13, 2007 at 10:28:15PM +0300, Vladimir Prus wrote: > > 3) I created this breakpoint by specifying the line but if I do: > > > > b foo<int>() > > > > or any variant I can think of, I just get a pending breakpoint as GDB > > doesn't recognise the location. Can such locations be specified on the > > command line by name? > > Does > > b 'void foo<int>()' > > work better? I have some patches in progress which should make 'break foo<int>' work. I posted one of them a month or so ago; I have not committed it yet, because I was disappointed by the performance cost, but I can't think of any real alternatives. So I probably will commit it soon and then finish the other patches. I've gotten caught up in another project at the moment, though, so not right away. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-13 19:28 ` Vladimir Prus 2007-11-13 19:59 ` Daniel Jacobowitz @ 2007-11-13 20:09 ` Nick Roberts 2007-11-13 20:14 ` Daniel Jacobowitz ` (3 more replies) 2007-11-13 22:18 ` Eli Zaretskii 2 siblings, 4 replies; 31+ messages in thread From: Nick Roberts @ 2007-11-13 20:09 UTC (permalink / raw) To: Vladimir Prus; +Cc: gdb > > (gdb) d 1.1 > > warning: bad breakpoint number at or near '1.1' > > Well, you can't really delete a location -- if breakpoint expression > corresponds to 20 addresses, that's the way it is -- you cannot delete > some of those addresses from the program ;-) It's not immediately obvious, at least to me, so I think this should be documented. Also I think error should be used for the message instead of warning as the requested task is not performed. The message could be more helpful too: (gdb) d 1.1 This breakpoint cannot be deleted on its own. > > 2) I can enable/disable 1 and this appears to enable/disable all the > > locations. > > Perhap this could be documented in the manual. > > Well yes. Patches welcome ;-) I don't want to detract from the fact that you have contributed a major patch but I think you should document your own changes. This is also a good idea because you understand the changes best. > > 3) I created this breakpoint by specifying the line but if I do: > > > > b foo<int>() > > > > or any variant I can think of, I just get a pending breakpoint as GDB > > doesn't recognise the location. Can such locations be specified on the > > command line by name? > > Does > > b 'void foo<int>()' > > work better? Yes, thanks. It seems strange to me that the return type needs to be specified. I thought with overloading, people talked about signature which is determined by the name and arguments but not the return type. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-13 20:09 ` Nick Roberts @ 2007-11-13 20:14 ` Daniel Jacobowitz 2007-11-13 20:18 ` Bob Rossi ` (2 subsequent siblings) 3 siblings, 0 replies; 31+ messages in thread From: Daniel Jacobowitz @ 2007-11-13 20:14 UTC (permalink / raw) To: Nick Roberts; +Cc: Vladimir Prus, gdb On Wed, Nov 14, 2007 at 09:09:05AM +1300, Nick Roberts wrote: > Yes, thanks. It seems strange to me that the return type needs to be > specified. I thought with overloading, people talked about signature which > is determined by the name and arguments but not the return type. It's a quirk of the way C++ gnuv3 mangling works. I get someone to explain to me why the return type is included about once a year, and then promptly forget again. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-13 20:09 ` Nick Roberts 2007-11-13 20:14 ` Daniel Jacobowitz @ 2007-11-13 20:18 ` Bob Rossi 2007-11-13 20:19 ` Vladimir Prus 2007-11-13 22:03 ` Andreas Schwab 3 siblings, 0 replies; 31+ messages in thread From: Bob Rossi @ 2007-11-13 20:18 UTC (permalink / raw) To: Nick Roberts; +Cc: Vladimir Prus, gdb On Wed, Nov 14, 2007 at 09:09:05AM +1300, Nick Roberts wrote: > > > (gdb) d 1.1 > > > warning: bad breakpoint number at or near '1.1' > > > > Well, you can't really delete a location -- if breakpoint expression > > corresponds to 20 addresses, that's the way it is -- you cannot delete > > some of those addresses from the program ;-) > > It's not immediately obvious, at least to me, so I think this should be > documented. Also I think error should be used for the message instead of > warning as the requested task is not performed. The message could be more > helpful too: > > (gdb) d 1.1 > This breakpoint cannot be deleted on its own. Yeah, this is yet another leaky abstraction. The common user has no idea why multiple breakpoints are created at once, and why they can not delete only one of the multiple added. I like the idea of showing the description. Perhaps with a reason why. > > > 2) I can enable/disable 1 and this appears to enable/disable all the > > > locations. > > > Perhap this could be documented in the manual. > > > > Well yes. Patches welcome ;-) > > I don't want to detract from the fact that you have contributed a major > patch but I think you should document your own changes. This is also a > good idea because you understand the changes best. Again, this is going to be something that is asked over and over. I think it'd be great to have it in the manual. Bob Rossi ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-13 20:09 ` Nick Roberts 2007-11-13 20:14 ` Daniel Jacobowitz 2007-11-13 20:18 ` Bob Rossi @ 2007-11-13 20:19 ` Vladimir Prus 2007-11-13 22:03 ` Andreas Schwab 3 siblings, 0 replies; 31+ messages in thread From: Vladimir Prus @ 2007-11-13 20:19 UTC (permalink / raw) To: Nick Roberts; +Cc: gdb On Tuesday 13 November 2007 23:09:05 Nick Roberts wrote: > > > (gdb) d 1.1 > > > warning: bad breakpoint number at or near '1.1' > > > > Well, you can't really delete a location -- if breakpoint expression > > corresponds to 20 addresses, that's the way it is -- you cannot delete > > some of those addresses from the program ;-) > > It's not immediately obvious, at least to me, so I think this should be > documented. Also I think error should be used for the message instead of > warning as the requested task is not performed. The message could be more > helpful too: > > (gdb) d 1.1 > This breakpoint cannot be deleted on its own. Indeed, the error message could be better. Though it would require each breakpoint-related function to be enhanced to recognize "N.M" and say it's not appropriate here. > > > 2) I can enable/disable 1 and this appears to enable/disable all the > > > locations. > > > Perhap this could be documented in the manual. > > > > Well yes. Patches welcome ;-) > > I don't want to detract from the fact that you have contributed a major > patch but I think you should document your own changes. This is also a > good idea because you understand the changes best. I've documented them, but you're finding the documentation not good ;-) Basically, as a practical matter it might take me a long time to get to any doc edits. - Volodya ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-13 20:09 ` Nick Roberts ` (2 preceding siblings ...) 2007-11-13 20:19 ` Vladimir Prus @ 2007-11-13 22:03 ` Andreas Schwab 2007-11-14 6:20 ` Vladimir Prus 3 siblings, 1 reply; 31+ messages in thread From: Andreas Schwab @ 2007-11-13 22:03 UTC (permalink / raw) To: Nick Roberts; +Cc: Vladimir Prus, gdb Nick Roberts <nickrob@snap.net.nz> writes: > Yes, thanks. It seems strange to me that the return type needs to be > specified. I thought with overloading, people talked about signature which > is determined by the name and arguments but not the return type. For function templates the return type is part of the signature (it can be parameterised with a template argument). Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, MaxfeldstraÃe 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-13 22:03 ` Andreas Schwab @ 2007-11-14 6:20 ` Vladimir Prus 2007-11-14 10:12 ` Andreas Schwab 0 siblings, 1 reply; 31+ messages in thread From: Vladimir Prus @ 2007-11-14 6:20 UTC (permalink / raw) To: gdb Andreas Schwab wrote: > Nick Roberts <nickrob@snap.net.nz> writes: > >> Yes, thanks. It seems strange to me that the return type needs to be >> specified. I thought with overloading, people talked about signature >> which is determined by the name and arguments but not the return type. > > For function templates the return type is part of the signature (it can > be parameterised with a template argument). I'm not sure it's true. Consider: template<class T> T foo(); template<class T> void bar(); The value of template parameter is indeed the part of signature. The return value does not seem to be, since it directly depends on template parameter, so: foo<int>() quite uniquely specify the type of return value. - Volodya ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-14 6:20 ` Vladimir Prus @ 2007-11-14 10:12 ` Andreas Schwab 2007-11-14 21:26 ` Jim Blandy 0 siblings, 1 reply; 31+ messages in thread From: Andreas Schwab @ 2007-11-14 10:12 UTC (permalink / raw) To: Vladimir Prus; +Cc: gdb Vladimir Prus <ghost@cs.msu.su> writes: > Andreas Schwab wrote: > >> Nick Roberts <nickrob@snap.net.nz> writes: >> >>> Yes, thanks. It seems strange to me that the return type needs to be >>> specified. I thought with overloading, people talked about signature >>> which is determined by the name and arguments but not the return type. >> >> For function templates the return type is part of the signature (it can >> be parameterised with a template argument). > > I'm not sure it's true. It is valid for function template instantiations to only differ in the return type. See <http://gcc.gnu.org/ml/gcc-bugs/2003-06/msg02798.html> for an example. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, MaxfeldstraÃe 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-14 10:12 ` Andreas Schwab @ 2007-11-14 21:26 ` Jim Blandy 2007-11-14 21:34 ` Vladimir Prus ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: Jim Blandy @ 2007-11-14 21:26 UTC (permalink / raw) To: Andreas Schwab; +Cc: Vladimir Prus, gdb Andreas Schwab <schwab at suse.de> writes: > It is valid for function template instantiations to only differ in the > return type. See <http://gcc.gnu.org/ml/gcc-bugs/2003-06/msg02798.html> > for an example. Following that link, I think I now better appreciate why full C++ support in GDB is basically impossible: in order to decide which 'fun' template the call in 'main' refers to, one must try to instantiate each template and type-check the resulting code. So GDB would need to essentially incorporate a full C++ front end. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-14 21:26 ` Jim Blandy @ 2007-11-14 21:34 ` Vladimir Prus 2007-11-14 22:08 ` Andreas Schwab 2007-11-15 4:08 ` Eli Zaretskii 2 siblings, 0 replies; 31+ messages in thread From: Vladimir Prus @ 2007-11-14 21:34 UTC (permalink / raw) To: gdb Jim Blandy wrote: > > Andreas Schwab <schwab at suse.de> writes: >> It is valid for function template instantiations to only differ in the >> return type. See <http://gcc.gnu.org/ml/gcc-bugs/2003-06/msg02798.html> >> for an example. > > Following that link, I think I now better appreciate why full C++ > support in GDB is basically impossible: in order to decide which 'fun' > template the call in 'main' refers to, one must try to instantiate > each template and type-check the resulting code. So GDB would need to > essentially incorporate a full C++ front end. Or have GCC export a library that GDB can use -- which seems right approach. Generally, overload resolution in C++ involves instantiating templates and evaluating constant expressions and yes, that requires knowing lots of things. - Volodya ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-14 21:26 ` Jim Blandy 2007-11-14 21:34 ` Vladimir Prus @ 2007-11-14 22:08 ` Andreas Schwab 2007-11-15 4:08 ` Eli Zaretskii 2 siblings, 0 replies; 31+ messages in thread From: Andreas Schwab @ 2007-11-14 22:08 UTC (permalink / raw) To: Jim Blandy; +Cc: Vladimir Prus, gdb Jim Blandy <jimb@codesourcery.com> writes: > Following that link, I think I now better appreciate why full C++ > support in GDB is basically impossible: in order to decide which 'fun' > template the call in 'main' refers to, one must try to instantiate > each template and type-check the resulting code. So GDB would need to > essentially incorporate a full C++ front end. It's even worse. You can put the function templates in different source files so that two function calls using the same parameters instantiate functions from different templates, all in the same program. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, MaxfeldstraÃe 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-14 21:26 ` Jim Blandy 2007-11-14 21:34 ` Vladimir Prus 2007-11-14 22:08 ` Andreas Schwab @ 2007-11-15 4:08 ` Eli Zaretskii 2007-11-15 13:37 ` Daniel Jacobowitz 2007-11-15 16:50 ` Jim Blandy 2 siblings, 2 replies; 31+ messages in thread From: Eli Zaretskii @ 2007-11-15 4:08 UTC (permalink / raw) To: Jim Blandy; +Cc: schwab, ghost, gdb > Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com > From: Jim Blandy <jimb@codesourcery.com> > Date: Wed, 14 Nov 2007 13:26:26 -0800 > > Following that link, I think I now better appreciate why full C++ > support in GDB is basically impossible: in order to decide which 'fun' > template the call in 'main' refers to, one must try to instantiate > each template and type-check the resulting code. So GDB would need to > essentially incorporate a full C++ front end. The information emitted by the compiler (which already has a full C++ implementation) could help, couldn't it? ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-15 4:08 ` Eli Zaretskii @ 2007-11-15 13:37 ` Daniel Jacobowitz 2007-11-15 16:50 ` Jim Blandy 1 sibling, 0 replies; 31+ messages in thread From: Daniel Jacobowitz @ 2007-11-15 13:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Jim Blandy, schwab, ghost, gdb On Thu, Nov 15, 2007 at 06:08:08AM +0200, Eli Zaretskii wrote: > > Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com > > From: Jim Blandy <jimb@codesourcery.com> > > Date: Wed, 14 Nov 2007 13:26:26 -0800 > > > > Following that link, I think I now better appreciate why full C++ > > support in GDB is basically impossible: in order to decide which 'fun' > > template the call in 'main' refers to, one must try to instantiate > > each template and type-check the resulting code. So GDB would need to > > essentially incorporate a full C++ front end. > > The information emitted by the compiler (which already has a full C++ > implementation) could help, couldn't it? It helps, but not much more than we use it already. The debug info isn't designed to include some of the extra details needed to figure out where things are visible and what all the options are. In my opinion, we do this well enough. Every once in a while I poke at doing overloading and template selection better in GDB, but what we have is adequate for most uses and the marginal work required to improve it is substantial. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-15 4:08 ` Eli Zaretskii 2007-11-15 13:37 ` Daniel Jacobowitz @ 2007-11-15 16:50 ` Jim Blandy 1 sibling, 0 replies; 31+ messages in thread From: Jim Blandy @ 2007-11-15 16:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: schwab, ghost, gdb Eli Zaretskii <eliz at gnu.org> writes: >> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com >> From: Jim Blandy <jimb@codesourcery.com> >> Date: Wed, 14 Nov 2007 13:26:26 -0800 >> >> Following that link, I think I now better appreciate why full C++ >> support in GDB is basically impossible: in order to decide which 'fun' >> template the call in 'main' refers to, one must try to instantiate >> each template and type-check the resulting code. So GDB would need to >> essentially incorporate a full C++ front end. > > The information emitted by the compiler (which already has a full C++ > implementation) could help, couldn't it? Actually, it doesn't. Did you follow the link Andreas posted? When the user enters a source expression referring to some function, and we have several function templates in scope under the given name, the process of deciding which function template's instantiation the user's expression actually refers to involves essentially trying out each template, typechecking its entire body, and rejecting the template if a problem arises. The debugging information could carry the templates' definitions to us, giving us enough information to do the work --- but the work itself is not much less complicated than a C++ front end. In practice, the debugging information does not carry the definitions of all the templates in scope, because it would often be huge. You will often have many templates in scope that you never used --- from header files, say. In order to carry out the process described above, the debugging information would need to carry the templates' complete definitions, including statements and expressions, not just summary information like what a C declaration carries. And those full definitions can be substantial. Restricting yourself to templates actually instantiated in the program would bring the size issue under control, but it doesn't address the 'complete C++ front end' issue. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-13 19:28 ` Vladimir Prus 2007-11-13 19:59 ` Daniel Jacobowitz 2007-11-13 20:09 ` Nick Roberts @ 2007-11-13 22:18 ` Eli Zaretskii 2007-11-13 23:39 ` Douglas Evans 2 siblings, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2007-11-13 22:18 UTC (permalink / raw) To: Vladimir Prus; +Cc: gdb > From: Vladimir Prus <ghost@cs.msu.su> > Date: Tue, 13 Nov 2007 22:28:15 +0300 > > > (gdb) d 1.1 > > warning: bad breakpoint number at or near '1.1' > > Well, you can't really delete a location -- if breakpoint expression > corresponds to 20 addresses, that's the way it is -- you cannot delete > some of those addresses from the program ;-) Sorry, I don't understand why; can you please elaborate? Removing a breakpoint instruction from a specific address is a primitive operation of the target back-end; why can't we use it for that single address? ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-13 22:18 ` Eli Zaretskii @ 2007-11-13 23:39 ` Douglas Evans 2007-11-14 4:17 ` Eli Zaretskii 0 siblings, 1 reply; 31+ messages in thread From: Douglas Evans @ 2007-11-13 23:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Vladimir Prus, gdb On Nov 13, 2007 2:18 PM, Eli Zaretskii <eliz@gnu.org> wrote: > > From: Vladimir Prus <ghost@cs.msu.su> > > Date: Tue, 13 Nov 2007 22:28:15 +0300 > > > > > (gdb) d 1.1 > > > warning: bad breakpoint number at or near '1.1' > > > > Well, you can't really delete a location -- if breakpoint expression > > corresponds to 20 addresses, that's the way it is -- you cannot delete > > some of those addresses from the program ;-) > > Sorry, I don't understand why; can you please elaborate? Removing a > breakpoint instruction from a specific address is a primitive > operation of the target back-end; why can't we use it for that single > address? I think it's a question of how much complexity one wants here. AIUI, the breakpoint is represented as source+line. One would have to augment that to mean source+line+except-this (I think). Also, it's not just "delete 1.1". It's also condition, commands, and ignore. I'm not suggesting all (or any) should be supported, just that we shouldn't tackle any of them without thinking the big picture through at least a bit. As of today, in the context of `delete, condition, commands, ignore' there is just one breakpoint with N sub-breakpoints (so to speak). [AIUI of course.] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-13 23:39 ` Douglas Evans @ 2007-11-14 4:17 ` Eli Zaretskii 2007-11-14 5:02 ` Joel Brobecker 2007-11-14 6:13 ` Vladimir Prus 0 siblings, 2 replies; 31+ messages in thread From: Eli Zaretskii @ 2007-11-14 4:17 UTC (permalink / raw) To: Douglas Evans; +Cc: ghost, gdb > Date: Tue, 13 Nov 2007 15:39:31 -0800 > From: "Douglas Evans" <dje@google.com> > Cc: "Vladimir Prus" <ghost@cs.msu.su>, gdb@sources.redhat.com > > On Nov 13, 2007 2:18 PM, Eli Zaretskii <eliz@gnu.org> wrote: > > > From: Vladimir Prus <ghost@cs.msu.su> > > > Date: Tue, 13 Nov 2007 22:28:15 +0300 > > > > > > > (gdb) d 1.1 > > > > warning: bad breakpoint number at or near '1.1' > > > > > > Well, you can't really delete a location -- if breakpoint expression > > > corresponds to 20 addresses, that's the way it is -- you cannot delete > > > some of those addresses from the program ;-) > > > > Sorry, I don't understand why; can you please elaborate? Removing a > > breakpoint instruction from a specific address is a primitive > > operation of the target back-end; why can't we use it for that single > > address? > > I think it's a question of how much complexity one wants here. AIUI, > the breakpoint is represented as source+line. One would have to > augment that to mean source+line+except-this (I think). Not necessarily. You could look up the struct bp_location that corresponds to 1.1 (by using its address as a key), and remove that struct bp_location from the chain we maintain for breakpoint 1. > Also, it's not just "delete 1.1". It's also condition, commands, and > ignore. Well, removing struct bp_location should take care of that as well. Am I missing something? > I'm not suggesting all (or any) should be supported, just that we > shouldn't tackle any of them without thinking the big picture > through at least a bit. Well, my big picture is that today we have no solution for the following use case: (a) I set a breakpoint that results in multiple locations; (b) I look at "info break" and realize that some of these locations are irrelevant for the problem I'm debugging, and I don't want the program to stop there (e.g., maybe stopping there will disrupt some timing); (c) I want to remove these locations from the breakpoints list. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-14 4:17 ` Eli Zaretskii @ 2007-11-14 5:02 ` Joel Brobecker 2007-11-14 6:13 ` Vladimir Prus 1 sibling, 0 replies; 31+ messages in thread From: Joel Brobecker @ 2007-11-14 5:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Douglas Evans, ghost, gdb > > I think it's a question of how much complexity one wants here. AIUI, > > the breakpoint is represented as source+line. One would have to > > augment that to mean source+line+except-this (I think). > > Not necessarily. You could look up the struct bp_location that > corresponds to 1.1 (by using its address as a key), and remove that > struct bp_location from the chain we maintain for breakpoint 1. The design issue occurs in certain situations when we have to recompute the breakpoint location addresses. For instance, when a shared library gets loaded, we recompute the breakpoint locations. So, when you delete a bp_location, we need to have a way of being able to make sure that it is not re-inserted the next time we recompute the breakpoint locations. We could compromise and have a caveat where GDB doesn't worry for now about remembering which bp_location we deleted. This might cause a bp_location to re-appear unexpectedly, but there will be some situations under which things should work fine. For instance, if the breakpoint is inserted after the program has been started and all shared libraries are loaded, as long as the program does not load manually extra shared libraries, it shouldn't be a problem. It's a bit dogdy, and will require ample documentation, but it's a thought. -- Joel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-14 4:17 ` Eli Zaretskii 2007-11-14 5:02 ` Joel Brobecker @ 2007-11-14 6:13 ` Vladimir Prus 2007-11-14 18:54 ` Eli Zaretskii 1 sibling, 1 reply; 31+ messages in thread From: Vladimir Prus @ 2007-11-14 6:13 UTC (permalink / raw) To: gdb Eli Zaretskii wrote: >> Date: Tue, 13 Nov 2007 15:39:31 -0800 >> From: "Douglas Evans" <dje@google.com> >> Cc: "Vladimir Prus" <ghost@cs.msu.su>, gdb@sources.redhat.com >> >> On Nov 13, 2007 2:18 PM, Eli Zaretskii <eliz@gnu.org> wrote: >> > > From: Vladimir Prus <ghost@cs.msu.su> >> > > Date: Tue, 13 Nov 2007 22:28:15 +0300 >> > > >> > > > (gdb) d 1.1 >> > > > warning: bad breakpoint number at or near '1.1' >> > > >> > > Well, you can't really delete a location -- if breakpoint expression >> > > corresponds to 20 addresses, that's the way it is -- you cannot >> > > delete some of those addresses from the program ;-) >> > >> > Sorry, I don't understand why; can you please elaborate? Removing a >> > breakpoint instruction from a specific address is a primitive >> > operation of the target back-end; why can't we use it for that single >> > address? Because after that, the output of 'info break' will no longer correspond accurately to what the program is. If there are 20 locations in program, and 'info break' shows 20 locations, it means the user sees *all* locations. He can disable some of them, and then he'll see that some of locations are disabled. If you allow removing a location, it means the list of location starts to show all locations except for previously removed ones, and there's no way to investigate which removed locations were there, how many are removed and so on. It seems to be that disabling undesired locations is more transparent approach. >> I think it's a question of how much complexity one wants here. AIUI, >> the breakpoint is represented as source+line. One would have to >> augment that to mean source+line+except-this (I think). > > Not necessarily. You could look up the struct bp_location that > corresponds to 1.1 (by using its address as a key), and remove that > struct bp_location from the chain we maintain for breakpoint 1. > >> Also, it's not just "delete 1.1". It's also condition, commands, and >> ignore. > > Well, removing struct bp_location should take care of that as well. > Am I missing something? > >> I'm not suggesting all (or any) should be supported, just that we >> shouldn't tackle any of them without thinking the big picture >> through at least a bit. > > Well, my big picture is that today we have no solution for the > following use case: (a) I set a breakpoint that results in multiple > locations; (b) I look at "info break" and realize that some of these > locations are irrelevant for the problem I'm debugging, and I don't > want the program to stop there (e.g., maybe stopping there will > disrupt some timing); (c) I want to remove these locations from the > breakpoints list. You disable those locations, and gdb no longer stops there. And GDB, furthermore, will try hard to keep those locations disabled as shared libraries are loaded and unloaded. - Volodya ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-14 6:13 ` Vladimir Prus @ 2007-11-14 18:54 ` Eli Zaretskii 2007-11-14 19:00 ` Vladimir Prus 0 siblings, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2007-11-14 18:54 UTC (permalink / raw) To: Vladimir Prus; +Cc: gdb > From: Vladimir Prus <ghost@cs.msu.su> > Date: Wed, 14 Nov 2007 09:13:16 +0300 > > >> > Sorry, I don't understand why; can you please elaborate? Removing a > >> > breakpoint instruction from a specific address is a primitive > >> > operation of the target back-end; why can't we use it for that single > >> > address? > > Because after that, the output of 'info break' will no longer correspond > accurately to what the program is. I need it to correspond to the way I want the program to be stopped, not to all possible ways a source-level locations specification can be interpreted in terms of an address. The latter is of course a correct starting point, but if I then chose that some of the addresses don't make sense for me, there's no reason I should see them just for completeness' sake. > > Well, my big picture is that today we have no solution for the > > following use case: (a) I set a breakpoint that results in multiple > > locations; (b) I look at "info break" and realize that some of these > > locations are irrelevant for the problem I'm debugging, and I don't > > want the program to stop there (e.g., maybe stopping there will > > disrupt some timing); (c) I want to remove these locations from the > > breakpoints list. > > You disable those locations, and gdb no longer stops there. That's just a workaround. The same logic could be used to argue that there's no need to have the "delete" command at all: you can always disable the critter. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-14 18:54 ` Eli Zaretskii @ 2007-11-14 19:00 ` Vladimir Prus 0 siblings, 0 replies; 31+ messages in thread From: Vladimir Prus @ 2007-11-14 19:00 UTC (permalink / raw) To: gdb Eli Zaretskii wrote: >> From: Vladimir Prus <ghost@cs.msu.su> >> Date: Wed, 14 Nov 2007 09:13:16 +0300 >> >> >> > Sorry, I don't understand why; can you please elaborate? Removing a >> >> > breakpoint instruction from a specific address is a primitive >> >> > operation of the target back-end; why can't we use it for that >> >> > single address? >> >> Because after that, the output of 'info break' will no longer correspond >> accurately to what the program is. > > I need it to correspond to the way I want the program to be stopped, > not to all possible ways a source-level locations specification can be > interpreted in terms of an address. The latter is of course a correct > starting point, but if I then chose that some of the addresses don't > make sense for me, there's no reason I should see them just for > completeness' sake. > >> > Well, my big picture is that today we have no solution for the >> > following use case: (a) I set a breakpoint that results in multiple >> > locations; (b) I look at "info break" and realize that some of these >> > locations are irrelevant for the problem I'm debugging, and I don't >> > want the program to stop there (e.g., maybe stopping there will >> > disrupt some timing); (c) I want to remove these locations from the >> > breakpoints list. >> >> You disable those locations, and gdb no longer stops there. > > That's just a workaround. The same logic could be used to argue that > there's no need to have the "delete" command at all: you can always > disable the critter. I disagree. breakpoint is something you create yourself, and it's natural you can delete something you've created. Locations exist in the program independent of you, and it's natural to be able to disable some locations. And, BTW, once you've deleted a breakpoint, you can create it afresh because you presumably remember how it was created. If you delete a location, how you recover it back? By deleting the breakpoint, creating it again, and losing enable/disable state on other unrelated locations? - Volodya ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-13 19:15 Multiple breakpoint locations Nick Roberts 2007-11-13 19:28 ` Vladimir Prus @ 2007-11-17 11:55 ` Eli Zaretskii 2007-11-17 12:07 ` Eli Zaretskii 2 siblings, 0 replies; 31+ messages in thread From: Eli Zaretskii @ 2007-11-17 11:55 UTC (permalink / raw) To: Nick Roberts; +Cc: gdb, gdb-patches > From: Nick Roberts <nickrob@snap.net.nz> > Date: Wed, 14 Nov 2007 08:15:27 +1300 > > > The new code for breakpoints with multiple locations looks very good and > addresses a common complaint about GDB. I have a couple of points and > apologise if they have already been discussed. Thanks for your suggestions, I fixed the manual as shown below: 2007-11-17 Eli Zaretskii <eliz@gnu.org> * gdb.texinfo (Set Breaks, Disabling): Clarify behavior of breakpoints with multiple locations. (Breakpoint Menus): Improve wording. Index: gdb/doc/gdb.texinfo =================================================================== RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v retrieving revision 1.444 diff -u -r1.444 gdb.texinfo --- gdb/doc/gdb.texinfo 15 Nov 2007 18:43:23 -0000 1.444 +++ gdb/doc/gdb.texinfo 17 Nov 2007 11:48:53 -0000 @@ -2992,7 +2992,7 @@ @item Enabled or Disabled Enabled breakpoints are marked with @samp{y}. @samp{n} marks breakpoints that are not enabled. An optional @samp{(p)} suffix marks pending -breakpoints --- breakpoints for which address is either not yet +breakpoints---breakpoints for which address is either not yet resolved, pending load of a shared library, or for which address was in a shared library that was since unloaded. Such breakpoint won't fire until a shared library that has the symbol or line referred by @@ -3001,7 +3001,7 @@ Where the breakpoint is in your program, as a memory address. For a pending breakpoint whose address is not yet known, this field will contain @samp{<PENDING>}. A breakpoint with several locations will -have @samp{<MULTIPLE>} in this field --- see below for details. +have @samp{<MULTIPLE>} in this field---see below for details. @item What Where the breakpoint is in the source for your program, as a file and line number. For a pending breakpoint, the original string passed to @@ -3060,16 +3060,16 @@ In all those cases, @value{GDBN} will insert a breakpoint at all the relevant locations. -A breakpoint with multiple locations is displayed in the -breakpoint table using several rows --- one header row, followed -by one row for each breakpoint location. The header row -has @samp{<MULTIPLE>} in the address column. The rows for -individual locations contain the actual addresses for locations, -and say what functions those locations are in. The number -column for a location has number in the format +A breakpoint with multiple locations is displayed in the breakpoint +table using several rows---one header row, followed by one row for +each breakpoint location. The header row has @samp{<MULTIPLE>} in the +address column. The rows for individual locations contain the actual +addresses for locations, and show the functions to which those +locations belong. The number column for a location is of the form @var{breakpoint-number}.@var{location-number}. For example: + @smallexample Num Type Disp Enb Address What 1 breakpoint keep y <MULTIPLE> @@ -3081,11 +3081,17 @@ Each location can be individually enabled or disabled by passing @var{breakpoint-number}.@var{location-number} as argument to the -@code{enable} and @code{disable} commands. +@code{enable} and @code{disable} commands. Note that you cannot +delete the individual locations from the list, you can only delete the +entire list of locations that be long to their parent breakpoint (with +the @kbd{delete @var{num}} command, where @var{num} is the number of +the parent breakpoint, 1 in the above example). Disabling or enabling +the parent breakpoint (@pxref{Disabling}) affects all of the locations +that belong to that breakpoint. @cindex pending breakpoints It's quite common to have a breakpoint inside a shared library. -The shared library may be loaded and unloaded explicitly, +Shared libraries can be loaded and unloaded explicitly, and possibly repeatedly, as the program is executed. To support this use case, @value{GDBN} updates breakpoint locations whenever any shared library is loaded or unloaded. Typically, you would @@ -3093,7 +3099,7 @@ debugging session, when the library is not loaded, and when the symbols from the library are not available. When you try to set breakpoint, @value{GDBN} will ask you if you want to set -a so called @dfn{pending breakpoint} --- breakpoint whose address +a so called @dfn{pending breakpoint}---breakpoint whose address is not yet resolved. After the program is run, whenever a new shared library is loaded, @@ -3544,6 +3550,9 @@ @code{info watch} to print a list of breakpoints, watchpoints, and catchpoints if you do not know which numbers to use. +Disabling and enabling a breakpoint that has multiple locations +affects all of its locations. + A breakpoint, watchpoint, or catchpoint can have any of four different states of enablement: @@ -3808,8 +3817,8 @@ to be defined several times, for application in different contexts. This is called @dfn{overloading}. When a function name is overloaded, @samp{break @var{function}} is not enough to tell @value{GDBN} where you want -a breakpoint. If you realize this is a problem, you can use -something like @samp{break @var{function}(@var{types})} to specify which +a breakpoint. You can use explicit signature of the function, as in +@samp{break @var{function}(@var{types})}, to specify which particular version of the function you want. Otherwise, @value{GDBN} offers you a menu of numbered choices for different possible breakpoints, and waits for your selection with the prompt @samp{>}. The first two ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-13 19:15 Multiple breakpoint locations Nick Roberts 2007-11-13 19:28 ` Vladimir Prus 2007-11-17 11:55 ` Eli Zaretskii @ 2007-11-17 12:07 ` Eli Zaretskii 2007-11-17 14:14 ` Vladimir Prus 2 siblings, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2007-11-17 12:07 UTC (permalink / raw) To: gdb > From: Nick Roberts <nickrob@snap.net.nz> > Date: Wed, 14 Nov 2007 08:15:27 +1300 > > > The new code for breakpoints with multiple locations looks very good and > addresses a common complaint about GDB. I have a couple of points and > apologise if they have already been discussed. Btw, while working on Nick's proposals, I found myself confused wrt the connection, if any, between the feature described in "Breakpoint Menus" and the multiple-location breakpoints that was the subject of this thread. Are these features the same (i.e., is the format of the multiple-locations breakpoint listing described in "Set Break" what we use for breakpoints set from the menu described in "Breakpoint Menus")? Or are they two different features? If the former, won't additional locations, which we didn't select from the menu, appear in the list of locations as result of loading shared libraries that define additional overloaded variants of the function in which we wanted to break? If the latter, I cannot seem to find the description of how multiple locations come into existence in the first place anywhere in the manual. Am I missing something? ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-17 12:07 ` Eli Zaretskii @ 2007-11-17 14:14 ` Vladimir Prus 2007-11-17 15:36 ` Eli Zaretskii 0 siblings, 1 reply; 31+ messages in thread From: Vladimir Prus @ 2007-11-17 14:14 UTC (permalink / raw) To: gdb Eli Zaretskii wrote: >> From: Nick Roberts <nickrob@snap.net.nz> >> Date: Wed, 14 Nov 2007 08:15:27 +1300 >> >> >> The new code for breakpoints with multiple locations looks very good and >> addresses a common complaint about GDB. I have a couple of points and >> apologise if they have already been discussed. > > Btw, while working on Nick's proposals, I found myself confused wrt > the connection, if any, between the feature described in "Breakpoint > Menus" and the multiple-location breakpoints that was the subject of > this thread. > > Are these features the same (i.e., is the format of the > multiple-locations breakpoint listing described in "Set Break" what we > use for breakpoints set from the menu described in "Breakpoint > Menus")? Or are they two different features? They are different. "Breakpoint menus" are for overloaded function, where a single name 'foo' may refer to completely different functions in source code. Multiple locations handle a case where a specific function in source corresponds to multiple PC values. > > If the former, won't additional locations, which we didn't select from > the menu, appear in the list of locations as result of loading shared > libraries that define additional overloaded variants of the function > in which we wanted to break? > > If the latter, I cannot seem to find the description of how multiple > locations come into existence in the first place anywhere in the > manual. Am I missing something? The manual lists cases where a given function in source can correspond to several PC values, and they say: In all those cases, @value{GDBN} will insert a breakpoint at all the relevant locations. So it happens automatically. - Volodya ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-17 14:14 ` Vladimir Prus @ 2007-11-17 15:36 ` Eli Zaretskii 2007-11-18 1:32 ` Nick Roberts 0 siblings, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2007-11-17 15:36 UTC (permalink / raw) To: Vladimir Prus; +Cc: gdb > From: Vladimir Prus <ghost@cs.msu.su> > Date: Sat, 17 Nov 2007 17:13:18 +0300 > > > If the latter, I cannot seem to find the description of how multiple > > locations come into existence in the first place anywhere in the > > manual. Am I missing something? > > The manual lists cases where a given function in source can correspond to > several PC values, and they say: > > In all those cases, @value{GDBN} will insert a breakpoint at all > the relevant locations. > > So it happens automatically. Well, I think it's not explicit enough. I will try to add some more explicit explanations when I have time. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-17 15:36 ` Eli Zaretskii @ 2007-11-18 1:32 ` Nick Roberts 2007-11-18 2:26 ` Daniel Jacobowitz 0 siblings, 1 reply; 31+ messages in thread From: Nick Roberts @ 2007-11-18 1:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Vladimir Prus, gdb > > The manual lists cases where a given function in source can correspond to > > several PC values, and they say: > > > > In all those cases, @value{GDBN} will insert a breakpoint at all > > the relevant locations. > > > > So it happens automatically. > > Well, I think it's not explicit enough. I will try to add some more > explicit explanations when I have time. The only way I've managed to create breakpoints at multiple locations is by specifying a line number inside the template/constructor. For templates I understand that the breakpoints are for different types, e.g., float, int as used by the program. For constructors: * For a C++ constructor, the GCC compiler generates several instances of the function body, used in different cases. I don't understand what the second breakpoint refers to, or why there may be more than one instance. So I think, at some point, a separate node, or one grouped with breakpoint menus to highlight the differences, would be a good idea. Other things, like needing to include the return type in the template name when specifying a breakpoint location could also be included. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-18 1:32 ` Nick Roberts @ 2007-11-18 2:26 ` Daniel Jacobowitz 2007-11-18 8:47 ` Nick Roberts 0 siblings, 1 reply; 31+ messages in thread From: Daniel Jacobowitz @ 2007-11-18 2:26 UTC (permalink / raw) To: Nick Roberts; +Cc: Eli Zaretskii, Vladimir Prus, gdb On Sun, Nov 18, 2007 at 02:32:42PM +1300, Nick Roberts wrote: > * For a C++ constructor, the GCC compiler generates several > instances of the function body, used in different cases. > > I don't understand what the second breakpoint refers to, or why there may > be more than one instance. GCC generates two copies of the constructor. One is used to construct whole objects; the other is used to construct not-in-charge virtual base classes. You can find out more about this at http://www.codesourcery.com/cxx-abi/ and in the C++ language standard, if you're interested. > So I think, at some point, a separate node, or one grouped with breakpoint > menus to highlight the differences, would be a good idea. Other things, like > needing to include the return type in the template name when specifying a > breakpoint location could also be included. If I can find the time, I hope to get this fixed before the end of the year. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-18 2:26 ` Daniel Jacobowitz @ 2007-11-18 8:47 ` Nick Roberts 2007-11-19 12:57 ` Daniel Jacobowitz 0 siblings, 1 reply; 31+ messages in thread From: Nick Roberts @ 2007-11-18 8:47 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Eli Zaretskii, Vladimir Prus, gdb > > So I think, at some point, a separate node, or one grouped with breakpoint > > menus to highlight the differences, would be a good idea. Other things, > > like needing to include the return type in the template name when > > specifying a breakpoint location could also be included. > > If I can find the time, I hope to get this fixed before the end of the > year. But Andreas has said that: "For function templates the return type is part of the signature" and "It is valid for function template instantiations to only differ in the return type." which suggests to me that the return type is a necessary part of the name. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple breakpoint locations 2007-11-18 8:47 ` Nick Roberts @ 2007-11-19 12:57 ` Daniel Jacobowitz 0 siblings, 0 replies; 31+ messages in thread From: Daniel Jacobowitz @ 2007-11-19 12:57 UTC (permalink / raw) To: Nick Roberts; +Cc: Eli Zaretskii, Vladimir Prus, gdb On Sun, Nov 18, 2007 at 09:46:53PM +1300, Nick Roberts wrote: > But Andreas has said that: > > "For function templates the return type is part of the signature" > > and > > "It is valid for function template instantiations to only differ in the > return type." > > which suggests to me that the return type is a necessary part of the name. True, but in most cases it is not necessary to disambiguate. Only in the rare cases where the program contains two instantiations which differ only in return type. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2007-11-19 12:57 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-11-13 19:15 Multiple breakpoint locations Nick Roberts 2007-11-13 19:28 ` Vladimir Prus 2007-11-13 19:59 ` Daniel Jacobowitz 2007-11-13 20:09 ` Nick Roberts 2007-11-13 20:14 ` Daniel Jacobowitz 2007-11-13 20:18 ` Bob Rossi 2007-11-13 20:19 ` Vladimir Prus 2007-11-13 22:03 ` Andreas Schwab 2007-11-14 6:20 ` Vladimir Prus 2007-11-14 10:12 ` Andreas Schwab 2007-11-14 21:26 ` Jim Blandy 2007-11-14 21:34 ` Vladimir Prus 2007-11-14 22:08 ` Andreas Schwab 2007-11-15 4:08 ` Eli Zaretskii 2007-11-15 13:37 ` Daniel Jacobowitz 2007-11-15 16:50 ` Jim Blandy 2007-11-13 22:18 ` Eli Zaretskii 2007-11-13 23:39 ` Douglas Evans 2007-11-14 4:17 ` Eli Zaretskii 2007-11-14 5:02 ` Joel Brobecker 2007-11-14 6:13 ` Vladimir Prus 2007-11-14 18:54 ` Eli Zaretskii 2007-11-14 19:00 ` Vladimir Prus 2007-11-17 11:55 ` Eli Zaretskii 2007-11-17 12:07 ` Eli Zaretskii 2007-11-17 14:14 ` Vladimir Prus 2007-11-17 15:36 ` Eli Zaretskii 2007-11-18 1:32 ` Nick Roberts 2007-11-18 2:26 ` Daniel Jacobowitz 2007-11-18 8:47 ` Nick Roberts 2007-11-19 12:57 ` Daniel Jacobowitz
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).