Re: Accessing size of arrays allocated on the stack

Re: Accessing size of arrays allocated on the stack

[Frank Ch. Eigler]

Hi, Alexander --

Alexander.Hoole wrote:

> I noticed that systemtap is able to know that a local variable, allocated on
> the stack, is an array.  [...]
> Does SystemTap presently support the ability to determine the size of local
> arrays using either built-in functionality or embedded C?

Not well.  There is a sizeof.stp sample, but that works for type names
that are resolvable via the @cast() construct, not general C type
declaration strings, and not references to a varable.  Via embedded-C
of course one can do anything one wants (return sizeof(some_c_type))
but that code doesn't have access to the DWARF data stap has
processed.

To get array bounds, stap would have to search for stuff like
DW_TAG_subrange_type -> DW_AT_upper_bound (which "extern array[];"
declarations won't have).  Stap would have to export this through
some new language feature, perhaps @byte_size($foo) (if one wants
all the array dimensions/element-sizes multiplied out).

- FChE

Accessing size of arrays allocated on the stack

[Alexander M. Hoole]

I noticed that systemtap is able to know that a local variable, allocated on
the stack, is an array.  For example, a program containing:

...
int main(int argc, char *argv[])
{
	char buf[40];
	unsigned long p;
	char *str;
...

With a probe containing:
...
probe process("./array_test").function("main").call {
	log (probefunc()." param: ".$$parms)
	log (probefunc()." locals: ".$$locals)
...

Produces
...
main param: argc=0x2 argv=0xbfeb9954
main local: buf=[...] p=0x160c7d7e str=0x3e9a9883
...

Does SystemTap presently support the ability to determine the size of local
arrays using either built-in functionality or embedded C?

Does this differ for user-space vs kernel-space probes?

Cheers,
A