This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Speed up find_pc_section


On Fri, Sep 11, 2009 at 1:50 PM, Tom Tromey <tromey@redhat.com> wrote:

> Paul> Perhaps I should just add a sequence number to 'struct objfile'? That
> Paul> looks like it would almost give exact same ordering as what GDB used
> Paul> before qsort+bsearch was introduced.
>
> Is there some benefit to the old ordering?

The only benefit I see is that it was deterministic (a section from an
earlier-added objfile always matched first and was returned).

With current sort/filter/bsearch we don't have that. If we enter "bad state"
(two sections overlap), it may happen that we sometimes return the one
from earlier-added objfile, and sometimes the one from the later-added
objfile.

This could lead to GDB bug reports which are harder to reproduce (your
qsort may produce a different final section order from my qsort even for
otherwise identical inputs).

> I assumed that the old approach just gave the user an arbitrary
> ordering, in which case any change here is no big deal.

Not completely arbitrary.

> But, if there
> is a benefit to the old ordering, sure, restore it.

I think there is -- reproducibility of the "bad state".

> How stable a sort would you want? ?You could just fall back to the
> objfile's address. ?Or is that too awful?

I don't think there is any advantage to that, as this will still lead to
essentially random ordering from one system to another.

Thanks,
-- 
Paul Pluzhnikov


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]