Hi,
On Mon, 12 Nov 2007, Alexandre Oliva wrote:
> With the design I've proposed, it is possible to compute the value of i,
No. Only if the function is reservible. There are many which aren't:
static inline int foo(int i)
{
return i % 10;
}
int foobar(int j)
{
return foo(j % 20);
}
int main(int argc, char **argv)
{
return foobar(argc);
}
If foo is inlined and foobar simplified (to return j%10), the value for
'i' (j % 20) can not be recovered anymore. Hence for a 100% solution (and
for systemtap you want that) you have no choice than to force the value to
be live, e.g. by a volatile asm or the like.
> As I wrote before, I'm not aware of any systemtap bug report about a
> situation in which an argument was actually optimized away.
I think it all started from PR23551. For us it also happened in the
kernel in namei.c, where real_lookup is inlined sometimes, and it's
arguments are missing. That might or might not be reversible functions,
so your scheme perhaps would have helped there. But generally it won't
solve the problem for good.
> I wouldn't go as far as stopping the optimization just so that systemtap
> can monitor the code.
Like I said, at some point you have to or accept that some code remains to
be not introspectable.
> > at which point you have to force the value of 'i' being live, if you
> > want to be sure that systemtap works in all cases.
>
> I don't want to be sure of that. At least that was not the problem I
> was asked to solve.
Then I'm probably still confused what problem you're actually trying to
solve. If you don't want to be sure you get precise location information
100% of the time, then what percentage are you required to get? And how
do you measure this? Or is the task rather "emit better debug info"? But
that can be done also in our scheme, so why is there a need for DEBUG_INSN
if it can't solve the systemtap problem for good?
> And, indeed, it's not solvable without disabling optimizations.
Ciao,
Michael.
