Re: [patch] XFAIL gdb.cp/mb-inline.exp conditionaly

[Pedro Alves <pedro@codesourcery.com>]

On Thursday 23 June 2011 10:21:21, Yao Qi wrote:
> On 06/22/2011 11:38 PM, Pedro Alves wrote:

> > The breakpoint was set by line number, and we're reloading
> > the session the same both times.  Why does breakpoint 1.2 become
> > enabled (and I'm guessing that breakpoint 1.1 becomes disabled)?
> > 
> 
> No, in my case, both 1.1 and 1.2 becomes enabled.
> info break^M
> Num     Type           Disp Enb Address    What^M
> 1       breakpoint     keep y   <MULTIPLE> ^M
>         breakpoint already hit 3 times^M
> 1.1                         y     0xe78c90a8 in foo(int) at
> gdb/testsuite/gdb.cp/mb-inline.h:26^M
> 1.2                         y     0xe78c91a8 in foo(int) at
> gdb/testsuite/gdb.cp/mb-inline.h:26^M
> 
> During breakpoint updates (when inferior is re-created), GDB will
> iterate list of breakpoint locations, to look for breakpoint locations
> for a certain address in new inferior, and assign found breakpoint
> locations to that breakpoint.  The state of breakpoint location
> (enabled/disabled) is kept, and this test will pass.
> 
> If gdb is unable to find any breakpoint location for a given address,
> gdb will create new breakpoint locations, and remove old breakpoint
> location.  Then, the state of breakpoint location of previous inferior
> is lost, and new created breakpoint location is enabled in default.

Okay, that happens when the locations have ambiguous names, at the
end of update_breakpoint_locations.

You're just re-running the same binary, and the breakpoints are even
all set in the same objfile.  Nothing changed from the user's
perpective.  It's reasonable to expect gdb manages to not lose track
of the disable state.  I think we can and should improve the heuristic
to handle this scenario.  

Instead of comparing
absolute addresses, normalize them before comparing.  E.g.,

Before             After
0x400010           0x800010
0x401000           0x801000
0x410000           0x810000
0x400100           0x800100

For each list, find some common base and subtract it from
each entry, and _then_ compare the locations:

Before             After
0x000010           0x000010
0x001000           0x001000
0x010000           0x010000
0x000100           0x000100

The common base might be the lowest address in each list,
or something else, like the objfile's lowest address, or
some such.  If we had some sort of unique symbol hash id,
we could use that instead, and it'd be more reliable, me
thinks.

-- 
Pedro Alves