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

Pedro Alves
2011-06-23T14:00:17Z

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