Re: Pinging Michael C

[David Carlton <carlton@math.stanford.edu>]

On Mon, 16 Sep 2002 11:09:21 -0400, Daniel Jacobowitz <drow@mvista.com> said:
> On Mon, Sep 16, 2002 at 10:55:47AM -0400, Fernando Nasser wrote:
>> Daniel Jacobowitz wrote:

>>> http://sources.redhat.com/ml/gdb-patches/2002-08/msg00695.html

>> I wonder if next will relly be more reliable.  Anyway, we can try
>> -- the test is not about breakpoints.

> I hadn't actually looked at this one.  David, there's an easier way
> - if you look in lib/gdb.exp, gdb_get_line_number.  Is that closer
> to what you want?  It should be more reliable than 'next'ing.

Honestly, I don't know if either of them is reliable, as is written.
The situation is that m-static.cc constructs a bunch of objects that
it doesn't do anything with; m-static.exp tries to stop after each
object is constructed, and then examine what the object looks like.

And it seems to me that, whether you use next or breakpoints (and
whether you do the latter with hard-coded numbers (blech), relative
offsets, or with gdb_get_line_number), you're going to run into
problems in that GDB might not be willing to stop at every line, and
that whether or not it is willing might depend on the specific
compiler, compiler options, etc. that are being used.

Personally, I don't see any reason why the test shouldn't just
construct all the objects before inspecting any of them with GDB.  So
what makes sense to me would be to put a breakpoint on the return line
(using gdb_get_line_number, presumably), run until that, and only then
inspect all the objects that have been constructed.

But if people don't like that, I'd prefer to stick with the current
next'ing (with a break +2 throw in for fun).  I think that would be as
reliable and easier to maintain than gdb_get_line_number.  The latter
only makes sense if people might later insert lines that should be
skipped in the middle of the extant constructors; that doesn't seem
too plausible to me.

>> The following ChangeLog entries need some more info though:
>> 
>> * gdb.c++/m-static.cc: Add test 4.
>> * gdb.c++/m-static.h: New file.
>> * gdb.c++/m-static1.cc: New file.

> (Fernando, this is exactly what the GNU coding standards say a
> ChangeLog entry should look like - just what changed, not why it was
> changed, which belongs only in the code.  What else are you looking
> for?)

I don't mind making them longer, but Andrew yells at me whenever I
include long comments.  So I'd rather not make the ChangeLog entries
more verbose without hearing from him first.

>> >  http://sources.redhat.com/ml/gdb-patches/2002-08/msg00472.html

>> I don't think we want to add tests to make gdb dump core to the 
>> testsuite right away.  It should go in as soon as someone fixes the 
>> problem to prevent a regression.  Alternatively we can add it in and 
>> explicitly skip the test with a explicit call to the kfail proc...

> Fortunately, David has since fixed the bug.  I think this patch is
> ready to go in, once we agree on ChangeLog formatting.

Right, and of course I'll update the comment in the .exp file
accordingly.


So would it be okay if I changed the test with all the next's to
construct all the objects before examining any of them, updated the
comments on the one test to reflect the fact that the bug has been
fixed, and then check them in?

David Carlton
carlton@math.stanford.edu