This is the mail archive of the
mailing list for the Archer project.
Re: Initial psymtab replacement results
>>>>> "Daniel" == Daniel Jacobowitz <email@example.com> writes:
Daniel> On Thu, Dec 17, 2009 at 09:20:44AM -0800, Paul Pluzhnikov wrote:
>> And building the cache "on demand" or at GDB install time is not a viable
Daniel> I think it's viable, but it'd be nice to pregenerate - that way you
Daniel> don't need per-user copies of the possibly large cache.
Daniel> I guess I should wait and see what sort of times Tom comes up with.
The problem I have with it is that it doesn't help the first time you
start gdb. And because the cache is invalidated whenever an objfile
changes, the part of your program you are hacking on will always look
like the first time.
I am still looking for a viable solution to this problem. Maybe we can
resurrect the index sections in some form.
I guess we could try resurrecting the sqlite stuff but do the writing in
a background thread. (The problem is what happens if the user quits gdb
while this is working.)
I spent the rest of this week changing gdb to read psymtabs in the
background. This works, though there is still some bug because the
result is slower than I think it ought to be... maybe I just need to
defer starting these threads until after the prompt shows up.
I'll go back to the index and cache stuff next week, and probably on
into next year.
I also plan to look into Jan's idea of using the shared library info to
limit searches by PC. This seems like it could help a case like ABRT,
which really just wants a stack trace and nothing else; in this case, we
could defer reading any debuginfo until it is requested, and then use
this change to pick exactly the objfile that matters. This seems like
an independent patch.