In the following example (which doesn't currently work because we don't support DW_AT_const_value yet), we get the scope wrong when probing func (inlined into main with gcc -O2): #include "sdt.h" struct foo { const int i; const long j; }; typedef struct foo fooer; static volatile int foobar; static int bar (const int i, const long j) { return i * j; } static int func (int (*f) ()) { const fooer baz = { .i = 2, .j = 21 }; STAP_PROBE (test, constvalues); return f(baz.i, baz.j); } int main (int argc, char *argv[], char *envp[]) { return func (&bar) - 42; } This is because of the following logic in dwarf_var_expanding_visitor::getscopes: // If the address is at the beginning of the scope_die, we can do a fast // getscopes from there. Otherwise we need to look it up by address. Dwarf_Addr entrypc; if (q.dw.die_entrypc(scope_die, &entrypc) && entrypc == addr) scopes = q.dw.getscopes(scope_die); else scopes = q.dw.getscopes(addr);
(In reply to comment #0) > This is because of the following logic [...] That, and also because the scope_die for process.mark("constvalues") is for main() instead of func(). I think all will be better if process.statement(PC) uses the inner-most scope_die that contains the PC, rather than how it currently uses just the subprogram die containing the PC.
(In reply to comment #1) > (In reply to comment #0) > > This is because of the following logic [...] > > That, and also because the scope_die for process.mark("constvalues") is for > main() instead of func(). Which is that way because func() gets inlined. So the workaround that is used in testsuite/systemtap.base/const_value.c for now is to explicitly mark the function as noinline (which isn't ideal because not all gcc versions seem smart enough to see that f is a const_value in that case, but gcc 4.5 for svn does see that it can be optimized that way even when not inlined).
This should be a better in commit 6b517475. I revamped the way that statement(NUM) is matched, and from the testsuite it seems to be solid. (In reply to comment #2) > So the workaround that is used in testsuite/systemtap.base/const_value.c > for now is to explicitly mark the function as noinline [...] I tried to remove this workaround, and while it can now find the variables, I'm still getting an error: semantic error: libdwfl failure (dwfl_addrmodule): no error This is while processing $f, in a call to dwflpp::emit_address. I can't figure out whether I broke something else, or if maybe that "no error" means that it doesn't need relocation on that address?
(In reply to comment #3) > I tried to remove this workaround, and while it can now find the variables, I'm > still getting an error: > > semantic error: libdwfl failure (dwfl_addrmodule): no error > > This is while processing $f, in a call to dwflpp::emit_address. I can't figure > out whether I broke something else, or if maybe that "no error" means that it > doesn't need relocation on that address? I should have written two testcases. I split the original one in two and removed the workaround from the original. commit e82cb6e94e5028637bdf0eedc0f6035139629a90 Author: Mark Wielaard <mjw@redhat.com> Date: Tue Oct 6 15:26:58 2009 +0200 PR10726 remove testcase workaround. * testsuite/systemtap.base/const_value.c: Allow inlining since PR10726 was fixed. I think your analysis of the issue is correct. I am tracking that as new bug PR10739. Closing this issue since it is solved. Thanks.