Re: RFC: The Constructor Breakpoint Issue

[Daniel Jacobowitz <drow@false.org>]

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
compilers.

> 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..  
> 
> Opinions??

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.

-- 
Daniel Jacobowitz