https://bugs.kde.org/show_bug.cgi?id=471807
--- Comment #9 from Mark Wielaard <m...@klomp.org> ---
(In reply to Aaron Merey from comment #8)
> (In reply to Mark Wielaard from comment #6)
> > Do we need a --enable-lazy-debuginfo=[yes|no] flag?
> > Is there any advantage to the user to set it to no?
> > Less variants in the code seems good.
>
> Maybe there are some cases where it is preferable for valgrind to
> minimize pausing execution of the client process? Downloading
> debuginfo as soon as the shared library is linked might be better
> here.
In that case it might be simpler to simply disable all debuginfo downloading.
If you think it really is an option people would use then ok.
But I do like to keep the number of (unused) options and code paths to a
minimum when possible.
> > I do wonder if addr_load_di can be made a bit cheaper. Currently it does a
> > search for the DebugInfo by calling find_DebugInfo which goes over the
> > debugInfo_list. find_DiCfSI does something similar. And describe_IP is
> > called with a InlIPCursor which already is associated with a particular
> > DebugInfo. I couldn't immediately find a way to "load" those DebugInfos
> > instead of calling addr_load_di, so maybe the "double" search is necessary.
>
> In patch v4, I added a load_di function that takes a debuginfo and ip
> and loads the debuginfo if the ip is in the appropriate text segment.
> This removes an unnecessary iteration over the debuginfo_list in
> find_DiCfSI. As for describe_IP, I think we still want to use addr_load_di
> in case the InlIPCursor is NULL.
Nice. Patch4 looks a lot more streamlined.
Can we do something like:
if (iipc && iipc->di)
VG_(load_di) (iipc->di, eip);
else
VG_(addr_load_di) (eip);
To reduce the extra search? And is the else part really necessary?
--
You are receiving this mail because:
You are watching all bug changes.
