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.

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

d.



On Thu, 2004-10-14 at 01:37, David Lecomber wrote:
> Specifically, this one:
> gdb/1091: Constructor breakpoints ignored
> gdb/1193: g++ 3.3 creates multiple constructors: gdb 5.3 can't set
> breakpoints
> 
> I see this happening in other situations.  For example, Intel's compiler
> seems to produce two versions of each subroutine -- perhaps each is
> optimized for a different architecture.  This means that, say, 'break
> test.f:65' will usually put the breakpoint in the wrong one (c.f.
> Murphy's Law).
> 
> I have implemented a fix, which works, presently I'm not too proud of
> it, so I'm going to check it through before proposing the patch
> formally..
> 
> However, does anyone have any problem with the approach.  
> 
> In summary, I change the linetable_entry structure to have a pointer,
> 'next', which will be the next linetable_entry in the table which has
> the same source code and line.  
> 
> find_line_pc then actually modifies the symtab_and_line parameter to get
> the linetable_entry (rather than just pulling the PC from it).
> 
> In the breakpoints code, if a symtab_and_line has several entries in the
> chain of entries, it sets a new breakpoint for each one.  
> 
> This does mean that break test.f:65 will announce each breakpoint
> separately.  Also, the first bpoint set is known by the line/source, the
> others can be distinguished by their address.
> 
> It cures the breakpoint in the constructor issue, which is probably the
> quickest way for a GNU compiler based check of the fix.
> 
> d.
> 
>