[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [valgrind] [Bug 79362] Debug info is lost for .so files when they are dlclose'd
From:       Philippe Waroquiers <bugzilla_noreply () kde ! org>
Date:       2017-08-01 7:22:31
Message-ID: bug-79362-17878-Qm0cKZrp6o () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=79362

--- Comment #67 from Philippe Waroquiers <philippe.waroquiers@skynet.be> ---
(In reply to Julian Seward from comment #66)
> (In reply to Philippe Waroquiers from comment #63)
> 
> Thanks for the feedback.  I'll fix the small stuff.
> 
> > * For execontext, instead of just storing the execcontext
> >   (e.g. in an mc chunk allocated by memecheck for each block), we now store
> >   an execontext + epoch.
> 
> I did consider this design, in some detail, but decided not to do that.
> Instead I kept semantics of ExeContext unchanged and added a new type
> ExeContextAndEpoch.
> 
> The problem is that we would lose the ability to do pointer-comparisons
> on ExeContext*s.  
What I suggest still allows to do pointer comparison (or ecu comparison)
and fully identify the epoch+addresses.

m_execontext.c would de-duplicate the (epoch + addresses).
So, even if after unmap and remap of some other lib, a bunch of addresses
would (by lack of chance) be the same, they would differ by their epoch,
and so that would give another execontext, only differing by the epoch.


> Currently, if two ExeContext*s (the addresses) are
> different then we are sure that the vectors of addresses are different
> (and vice versa), because m_execontext.c carefully de-duplicates them.
> And I was unsure what to do about maintaining those semantics if we add
> an epoch to ExeContext.
What I suggest is to consider the epoch part of the execontext itself,
and so, the same set of addresses but another epoch would give another
execontext.

To ensure this, the idea is to store 'invalid epoch' in an execontext
when adding it. When an debug info is  unloaded, all execontext with
an invalid epoch that have an address inside the unloaded debug info
are marked with the current epoch.

With that idea, an execontext reference (so either a ptr or an ecu)
will uniquely identify a set of address and its epoch.
That decreases the memory (e.g. for memcheck in an MC_Chunk)
or in the track origin (which can only store an ecu).

> 
> That said, fixing XTree, the GDB server and all the other tools (if it
> is possible) would be a good thing.

-- 
You are receiving this mail because:
You are watching all bug changes.=
[prev in list] [next in list] [prev in thread] [next in thread]