This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDB 7.4 branching status? (2011-11-23)


Thanks, Tom, for sending out a summary (this started out as an informal
discussion on IRC while asking Tom questions about what we were seeing
when we tried the patch out).

On second thoughts, I don't think the heuristics I proposed are
going to work. It's easy to defeat by trying to insert a breakpoint
inside a generic function (procedure Second is our Generic/Template
function here):

     7     procedure Second is
     8     begin
     9        Do_Nothing;
    10     end Second;
    11
    12     procedure Third is
    13     begin
    14        Do_Nothing;
    15     end Third;

With that, AdaCore's GDB yields:

    (gdb) b pck.adb:9
    [0] cancel
    [1] all
    [2] pck.third  <<<<----------  This one is wrong
    [3] foo.good_second

So, the idea of marking the lines below the first line of code
as suspect doesn't work. All we need is to produce the issue is
a "hole" in the linetable.

Heuristic 4 (where exact matches in a given symtab, as determine by
dirname + filename override inexact matches) isn't bad, and I think
it would prevent us from seeing the problem with generics above.
That's actually what we do today, except that we don't do the
dirname + filename check, because we're only concerned with returning
one single location.

However, I think it would miss some location as I explained using
my example with inlined functions. I think that it's a bit of
a corner case, but still legitimate.

On the other hand, the other heuristic that I like the most so far
is the simplest one, which takes the first line we find, inexact
and all. The downside is that we'll have too many matches.

> A couple of observations.
> 
> First, I think having too many locations is better than having too few.
> With too many, at least the user can disable some.  With too few,
> whoops, gdb isn't doing as asked.
> 
> Second, at least initially the heuristic only has to perform as well as
> what gdb already does.

I agree.

Right now, we're stuck between a rock and a hard place. So it's
more of a matter of deciding which approach matches our goals
the most. If we go by the principles above, the simpler heuristic
seems the way to go. It introduces an apparent regression for Ada,
but I don't see a simple way around it that does not sacrifice
a little bit of the principles above. We're just going to have
to call it a limitation.

-- 
Joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]