Re: debuginfoless static user probes

[fche at redhat dot com (Frank Ch. Eigler)]

Stan Cox <scox@redhat.com> writes:

> [...]
> +function _dwarf_register_regs() {
> +   _x8664_dwarf_regs["rax"] = 0 _x8664_dwarf_regs["eax"] = 0
> +   _x8664_dwarf_regs["ax"] = 0 _x8664_dwarf_regs["al"] = 0
> [...]

Can we hard-code this kind of lookup table inside the translator?
It's just as fixed as the loc2c mappings.


> +function _stp_u_fetch_register:long (dwarf_regno:long) %{ /* pure */
> +
> +   uintptr_t value;
> +   long dwarf_regno = THIS->dwarf_regno;
> +   value = u_fetch_register(dwarf_regno);
> +   THIS->__retvalue = value;
> +%}
> +
> +function _stp_k_fetch_register:long (dwarf_regno:long) %{ /* pure */
> +   uintptr_t value;
> +   long dwarf_regno = THIS->dwarf_regno;
> +   switch (dwarf_regno) {
> +   case 0: value = k_fetch_register(0);break;
> [...]
> +   case 15: value = k_fetch_register(15);break;
> +   }
> +   THIS->__retvalue = value;
> +%}

I see why you're doing this, but I'm ambivalent whether this sort of
extension of the tapset proper is the best way.

Another one would be to synthesize such embedded-C functions
on-demand, just like we do for loc2c content.

Another one would be to introduce the possibility of embedded-C
*expressions* in the parse tree, so that the tapset-mark.cxx code
could emit the equivalent of

     val = %{ (int64_t) k_fetch_register(0) %}

(assumed to be an int64_t valued C expression)
instead of 

     function __foo0 () %{ THIS->__retvalue = k_fetch_register(0); %}
     val = __foo0 ()


Such a construct need not necessarily be parsed, thus available to
end-user scripts.  Though it would make some things easier.  It could
constitute a way to access kernel value macros.


- FChE