RFC: The Constructor Breakpoint Issue
Fri Oct 15 14:52:00 GMT 2004
On Fri, Oct 15, 2004 at 02:41:39PM +0100, David Lecomber wrote:
> Morning all,
> I have reformatted this so it actually compiles - I hope...
> Unfortunately this patch busts a lot of test cases (about 30..). I
> have discovered that it is being over-zealous in applying breakpoints
> and need an expert to suggest solutions.
> The first broken example is gdb.base/display.c - there we have a for
> loop. So, first line of the for loop (display.c:14) is at PC xxxxxx,
> and also at xxxxxx + some no. which presumably is where the increment
> part of the for loop occurs. Do we want to get both these addresses for
> breakpoints, or not.. because it happens..
> I see the intel compiler sets the default is_stmt field to zero, and
> never does anything else with it, and the GNU compilers set it to 1.
> However, dwarf2read ignores this info anyway.
Yes; I've been thinking on and off about fixing this for the GNU
> I cannot see anything in the dwarf2 line info that enables us to
> distinguish between the two cases - those where the lines are not really
> duplicate, and those that are. I think everyone would find fixing this
> issue important..
You can't tell from the line table. You can tell if you have both a
line table and a .debug_info section; in the case that is interesting
to you, the two PCs will be in different DW_TAG_subprogram trees.
Given the order in which we parse things I'm not sure if you'll be able
to check that easily.
I don't much like the idea of your hack. However, since no one has
had the time for a thorough fix _still_, if you can get it to work, it
may be a good idea.
I haven't looked at your implementation yet, though.
More information about the Gdb-patches