This is the mail archive of the
mailing list for the systemtap project.
RE: tcp_test.stp failed to run in my IA64 box
- From: Roland McGrath <roland at redhat dot com>
- To: "Mao, Bibo" <bibo dot mao at intel dot com>
- Cc: "David Smith" <dsmith at redhat dot com>, "Systemtap List" <systemtap at sources dot redhat dot com>
- Date: Fri, 21 Jul 2006 01:02:09 -0700 (PDT)
- Subject: RE: tcp_test.stp failed to run in my IA64 box
> My kernel version is RHEL4-U3, and elfutils is 0.122, it failed in my
> IA64 box but succeeded in my x86_64 box, I doubt whether there is
> something architecture relative about $return value parsing.
Surely the parsing should not differ, no. The cited error messages
"semantic error: unresolved target-symbol expression: identifier '$return'"
sure sound like some sort of parsing problem. With -vv or more, you should
see a "literal_stmt_for_return: finding return value for " message if the
parsing is going right. I don't know why it is not failing more gracefully.
It should be getting a failure from dwfl_module_return_value_location.
This does: throw semantic_error("failed to retrieve return value location");
What it ought to do is a dwfl_assert or something similar that gets the
specific error message from libdwfl. The one you should get is "cannot
handle DWARF type description". Maybe David can help fix things on the
systemtap end so that this error is diagnosed properly.
That error would be because the elfutils backend support for return value
locations is missing for ia64. I didn't get around to it because ia64's
ABI definition is extraordinarily hairy and I didn't spend the time writing
the code to handle all the complex cases to spec. However, handling the
simple cases is not hard, and those are probably the only ones that will
come up any time soon in kernel probes. The x86_64 spec is also quite
hairy for some complex cases and I didn't do the complete support there.
I can whip something partial up for ia64 and put it in the next elfutils