[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:       Julian Seward <bugzilla_noreply () kde ! org>
Date:       2017-07-31 14:09:41
Message-ID: bug-79362-17878-OE0dbNH6PB () http ! bugs ! kde ! org/
[Download RAW message or body]

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

Julian Seward <jseward@acm.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #68213|0                           |1
        is obsolete|                            |
  Attachment #75779|0                           |1
        is obsolete|                            |

--- Comment #62 from Julian Seward <jseward@acm.org> ---
Created attachment 106984
  --> https://bugs.kde.org/attachment.cgi?id=106984&action=edit
epochs-3.diff

Here's a patch against 3.13.0.  It works only for the tools "none" and
"memcheck" -- currently it disables building of all other tools.  It should
be able to generate suppressions for unloaded libraries too, although I
haven't tested that.

This is a from-scratch implementation.  I couldn't convince myself that the
use of ExeContext uniques was reliable and the more I looked into it, the
more doubts I had.  This patch adds two new types:

* DiEpoch, which is just a wrapper around a 32 bit unsigned integer.
  These mark points in time where debuginfo is loaded or unloaded.

* ExeContextAndEpoch.  This is a pairing of an ExeContext (an array of code
  addresses that is a stack trace) and the DiEpoch in which it should be
  interpreted.

The core idea is that an ExeContext is still a stack trace, but one that
can't be symbolised.  To symbolise it, we need to specify a DiEpoch too,
hence this pairing.  In many places, the patch replaces uses of ExeContext*
with ExeContextAndEpoch.

Each DebugInfo structure acquires two new DiEpoch fields which indicate the
first and last epochs for which they are valid.  There is still only one top
level list of DebugInfo structures, which holds both the "active" and
"archived" DebugInfos.  They are distinguished by having the last-epoch
field be set to DiEpoch_INVALID() for an active structure, and to a valid
value to an archived structure.

From a user's point of view, the default behaviour of the patch is still to
discard debuginfo -- at least for now.  To retain it, use
--keep-debuginfo=yes.  You can see the difference if you run with -v.  Then
you will see messages of the form

  Discarding syms at [..] due to munmap()    with --keep-debuginfo=no

but

  Archiving syms at [..] due to munmap()    with --keep-debuginfo=no

Two things that I don't know if I kludged correctly or not, are the GDB
server support and the XTree support.  In both cases these just symbolise
against the current epoch, when it is necessary to do so.  So their
behaviour should at least be unchanged from before, even if they are not yet
"epoch-aware".

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