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

[Yao Qi <yao at codesourcery dot com>]

On 06/23/2011 06:28 PM, Pedro Alves wrote:
> 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.  
> 

Yes, this heuristics can be improved.  I have had a local hack similar
to what you suggest below, and this hack works for me.

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

The key point of this approach is about identifying common base.

My hack is similar to yours.  In my hack, the offset of objfile
relocation O1 is cached.  When new inferior is created again and new
object of objfile relocation offset O2 is got, we can compute the offset
A between offset of previous inferior's relocation offset (O1) and
current inferior's (O2), and then we can "relocate" breakpoint locations
with offset A.  Again, it is still a hack, and some more work may be
needed here.

Anyway, I'll think of this problem.

-- 
Yao (éå)