public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "m.lesniewski at samsung dot com" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug breakpoints/14844] New: Tracepoints are not reinserted in reloaded libraries.
Date: Thu, 15 Nov 2012 13:21:00 -0000	[thread overview]
Message-ID: <bug-14844-4717@http.sourceware.org/bugzilla/> (raw)

http://sourceware.org/bugzilla/show_bug.cgi?id=14844

             Bug #: 14844
           Summary: Tracepoints are not reinserted in reloaded libraries.
           Product: gdb
           Version: 7.5
            Status: NEW
          Severity: normal
          Priority: P2
         Component: breakpoints
        AssignedTo: unassigned@sourceware.org
        ReportedBy: m.lesniewski@samsung.com
    Classification: Unclassified


Created attachment 6738
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6738
Example program, library and test script

Tracepoints in shared libraries are not reinserted if the library is unloaded
and loaded back again.

Here's the scenario that illustrates this in detail:
1. A process loads a shared library explicitly using dlload
2. GDB Server attaches to the process
3. The user starts GDB; attaches to the remote target; defines a tracepoint in
the loaded library; starts the trace experiment (using tstart) and lets the
program continue;
4. The process unloads the library using dlclose;
5. The process loads the library again using dlload;

After this, the tracepoint is not inserted. No traceframes are created when
execution reaches the tracepoint location. 

I attached a simple example, which allows to reproduce the error. In the
archive there are two source files -- one for the program and one for the
library. 

The program loads the library, calls a function named "foo" from the library
ten times and unloads the library. This is repeated 10 times, so "foo" is
called 100 times in total. 

In the archive there is also a script run-test.sh, which builds the binaries,
starts gdbserver and gdb. GDB executes another script, which sets a tracepoint
in the library, launches the trace experiment and displays the number of
tracepoint hits just before the process exits.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


             reply	other threads:[~2012-11-15 13:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-15 13:21 m.lesniewski at samsung dot com [this message]
2012-11-15 14:05 ` [Bug breakpoints/14844] " m.lesniewski at samsung dot com
2012-11-15 14:05 ` m.lesniewski at samsung dot com
2012-11-15 14:21 ` qiyao at gcc dot gnu.org
2012-11-15 14:47 ` palves at redhat dot com
2012-11-15 14:55 ` palves at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-14844-4717@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).