This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug translator/13486] pass-4 error (frame_base undeclared), inlined function argument


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]