https://bugs.kde.org/show_bug.cgi?id=471807
Aaron Merey <ame...@redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #160375|0 |1
is obsolete| |
--- Comment #8 from Aaron Merey <ame...@redhat.com> ---
Created attachment 160636
--> https://bugs.kde.org/attachment.cgi?id=160636&action=edit
patch v4
(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 reply to Mark Wielaard from comment #7)
> v3 does work. But I admit to not fully understand why/how.
> The addr_load_di calls in coregrind/m_stacktrace..c seems unnecessary (you
> can comment them out and things still work fine).
> This is because there is a addr_load_di call in describe_IP and find_DiCfSI.
> Which makes sense since those methods are called when the debuginfo for an
> executable address are consulted.
Nice catch.
> 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.
--
You are receiving this mail because:
You are watching all bug changes.
