This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/13486] pass-4 error (frame_base undeclared), inlined function argument
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Thu, 27 Sep 2012 00:57:17 +0000
- Subject: [Bug translator/13486] pass-4 error (frame_base undeclared), inlined function argument
- Auto-submitted: auto-generated
- References: <bug-13486-6586@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=13486
Josh Stone <jistone at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jistone at redhat dot com
--- Comment #2 from Josh Stone <jistone at redhat dot com> 2012-09-27 00:57:17 UTC ---
(In reply to comment #0)
> I don't see a location list for this "mapcount" variable, but that must just be
> my lyin' eyes.
I believe that's because you only quoted the "subprogram" section for the
inline, which is basically just info shared across all instances. You need the
particular "inlined_subroutine" to get actual location lists.
Your rmap.o shows this at ead9, with mapcount at eb03 and location list 5dcb.
This is an implicit_pointer to die e858 with location list 58df. And part of
that list indeed references fb_reg -172, as in your generated C.
I can't reproduce the issue with your script on a current F17 kernel, as I get
just "not accessible at this address". But I just ran into this elsewhere:
$ stap -e 'probe process.function("seen_triple") { println($ht) }' -c df -p4
/tmp/stapPYTjE4/stap_7fb9f85209eb688e311d35324c1e6749_1395_src.c: In function
âfunction__dwarf_tvar_get_ht_0â:
/tmp/stapPYTjE4/stap_7fb9f85209eb688e311d35324c1e6749_1395_src.c:118:16: error:
âframe_baseâ undeclared (first use in this function)
And the symptoms are the same, an inline function parameter resolving to an
implicit_pointer to something else that references fb_reg.
I figured out that loc2c.c:c_emit_location() only emits code for frame_base if
it's on the first loc of the chain. But in this case, the loc_implicit_pointer
has no frame_base, yet its ->pointer.target does. That target comes later in
the chain, thus we get a reference to frame_base without defining it.
I'm testing this patch to look if *any* of the loc chain needs frame_base, and
so far it seems to work:
diff --git a/loc2c.c b/loc2c.c
index 16b8c8e..7c4ec60 100644
--- a/loc2c.c
+++ b/loc2c.c
@@ -2538,9 +2538,13 @@ c_emit_location (FILE *out, struct location *loc, int
indent,
bool deref = false;
*max_stack = 0;
- if (loc->frame_base != NULL)
- emit_loc_value (out, loc->frame_base, indent, "frame_base", true,
- &deref, max_stack);
+ for (l = loc; l != NULL; l = l->next)
+ if (l->frame_base != NULL)
+ {
+ emit_loc_value (out, l->frame_base, indent, "frame_base", true,
+ &deref, max_stack);
+ break;
+ }
for (; loc->next != NULL; loc = loc->next)
switch (loc->type)
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.