This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-0.9.8-184-gf982c59
- From: Mark Wielaard <mjw at redhat dot com>
- To: systemtap at sourceware dot org
- Cc: Josh Stone <jistone at redhat dot com>
- Date: Tue, 21 Jul 2009 13:18:57 +0200
- Subject: Re: [SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-0.9.8-184-gf982c59
- References: <20090721012207.17368.qmail@sourceware.org>
Hi Josh,
On Tue, 2009-07-21 at 01:22 +0000, jistone@sourceware.org wrote:
> commit 0c16d51256bc77c2b5497b72ec43b7864d2b47a8
> Author: Josh Stone <jistone@redhat.com>
> Date: Mon Jul 20 16:32:33 2009 -0700
>
> Allow dwflpp to take a vector of module names
>
> This will be used to load tracepoint modules as a bunch of little query
> modules into a single dwflpp.
>
> * dwflpp.cxx (setup_user): take a vector instead of a single module
> (dwflpp::dwflpp): form a vector in the singular case, and add a
> variant that takes and passes through a vector of modules.
This breaks user space mark probing. See make installcheck
RUNTESTFLAGS="sdt.exp exelib.exp" for example.
Most stuff will fail with "semantic error: libdwfl failure
(getshdrstrndx): no error while resolving probe point"
Which comes from dwarf_builder::probe_table::probe_table().
What goes wrong is that probe_table will try to fetch the probe table
(initiated through dwarf_builder::build) from the dw module (initialized
through dw = get_user_dw(sess, module_name)), if (get_param(parameters,
TOK_MARK, mark_name)). But at that point dw->module isn't setup yet.
I am not completely sure how to correct this.
The following hack makes things work as before:
diff --git a/dwflpp.cxx b/dwflpp.cxx
index 0bba3f1..38be86b 100644
--- a/dwflpp.cxx
+++ b/dwflpp.cxx
@@ -418,6 +418,7 @@ dwflpp::setup_user(const vector<string>& modules, bool debug
module_name.c_str(),
-1);
// XXX: save mod!
+ module = mod;
if (debuginfo_needed)
dwfl_assert (string("missing process ") +
That works, since it mimics what happened before your patch. And because
there is really only one module name in the vector anyway.
I checked it in so things at least work again for now.
But it seems there must be a better/more elegant solution.
Cheers,
Mark