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

[Pedro Alves <pedro at codesourcery dot com>]

On Thursday 23 June 2011 14:40:07, Yao Qi wrote:
> 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.

Yes, that'd be a good approach.  But you don't have a single
offset though.  You have potentialy one relocation offset per segment, or
one per section.  And its not clear locations set at addresses (b *0xf00)
rather than though symbols should be relocated.  At
<http://sourceware.org/ml/gdb-patches/2009-06/msg00668.html> I outline
"cooked" vs "raw" addresses, that I think would be an even better long
term goal, which is sort of a superset of all this in that it treats
addresses as base+offset.  Hmmm, going back to the current mechanism, I
wonder if we could use offset into section as common base (and also
compare if the sections are the same).

> 
> Anyway, I'll think of this problem.
> 
> 

-- 
Pedro Alves