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.
next 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: linkBe 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).