R.F.C. Should we abandon User-land probes?

R.F.C. Should we abandon User-land probes?

[James Dickens]

Hi

Because of Systemtap's language lack of support for structs, unions,
typedefs, Systemtap ends up just being a counter, couldn't a userland
app be written to count the number of times a function is called.

The lack of support for those language construct is bad enough for
kernel probes, it can be worked around with pre-made tapsets, but are
we going to write custom tapsets for every app every written?

Guru-mode is no solution, do we have to disable all the work the
Systemtap coders to make Systemtap as safe as possible. Guru-mode can
never be used in a production system without lots of testing. In the
end it would be easier to use other methods, to debug the problem.
Resorting to Guru-mode makes the system unstable. You end up debugging
your script, instead of debugging the app.

Further more, the chance of having an app pass a bad pointer increases
dramatically and may even be the reason they are probing the app in
the first place.  As we all know passing a bad pointer in a userland
app, crashes the app, but do the same in the kernel we get an oops, or
the system crashes. You may even write code to handle such events in
Systemtap but that isn't used in guru-mode.

The only way I see that Systemtap can be useful with userland probes
is to implement support for structs, unions and typedefs. It would be
even more helpful if you implement cpp support, so you can include
header files into scripts.

James Dickens

Re: R.F.C. Should we abandon User-land probes?

[Frank Ch. Eigler]

jamesd.wi wrote:

> [...] The only way I see that Systemtap can be useful with userland
> probes is to implement support for structs, unions and typedefs.
> [...]

Do you mean you want to build complex structures in your script?  If
so, what does this have to do with probing that targets kernel vs user
space?  Or else are you under the impression that systemtap can't
know/expose such structured data types present in the probed target
software?  Perhaps you need to pay more attention to the project
instead of chicken-little editorializing.

- FChE

Re: R.F.C. Should we abandon User-land probes?

[James Dickens]

On 20 Oct 2005 14:53:14 -0400, Frank Ch. Eigler <fche@redhat.com> wrote:
[snip]
>
> Do you mean you want to build complex structures in your script?  If
> so, what does this have to do with probing that targets kernel vs user
> space?  Or else are you under the impression that systemtap can't
> know/expose such structured data types present in the probed target
> software?  Perhaps you need to pay more attention to the project
> instead of chicken-little editorializing.

No I want to access components of complex structures that are pasted
to user land functions. Rarely do complex userland apps just use  int,
long, and char *'s. This is especially the case with C++ that pass
class structures. Yes you can make this work in gurumode, but as i
said this disables all the saftety measures systemtap programmers have
worked on.

James
>
> - FChE
>

Fwd: R.F.C. Should we abandon User-land probes?

[James Dickens]

oops meant that to go to the mailing list as well

---------- Forwarded message ----------
From: James Dickens <jamesd.wi@gmail.com>
Date: Oct 20, 2005 3:02 PM
Subject: Re: R.F.C. Should we abandon User-land probes?
To: "Frank Ch. Eigler" <fche@redhat.com>




On 10/20/05, Frank Ch. Eigler <fche@redhat.com> wrote:
>  Hi -
>
> > No I want to access components of complex structures that are pasted
> > to user land functions. [...]
>
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=905

 yes those work fine in kernel code, since variables to access
components of the structs/unions are allready availible for the
systemtap code and tapsets, but that is not the case of userland,
especially in the case of C++ classes/struct. So the user required to
enable guru-mode.

 perhaps, you can enable  guru-mode for including structs, but this of
course can polute the namespace.

 James


> - FChE
>
>
>

Re: Fwd: R.F.C. Should we abandon User-land probes?

[Martin Hunt]

On Thu, 2005-10-20 at 15:06 -0500, James Dickens wrote:

>  yes those work fine in kernel code, since variables to access
> components of the structs/unions are allready availible for the
> systemtap code and tapsets, but that is not the case of userland,
> especially in the case of C++ classes/struct. So the user required to
> enable guru-mode.

Whatever gave you that idea?

Martin

Re: Fwd: R.F.C. Should we abandon User-land probes?

[James Dickens]

On 10/20/05, Martin Hunt <hunt@redhat.com> wrote:
> On Thu, 2005-10-20 at 15:06 -0500, James Dickens wrote:
>
> >  yes those work fine in kernel code, since variables to access
> > components of the structs/unions are allready availible for the
> > systemtap code and tapsets, but that is not the case of userland,
> > especially in the case of C++ classes/struct. So the user required to
> > enable guru-mode.
>
> Whatever gave you that idea?

because systemtap doesn't understand struct/union etc. how would it
know what are the members of the struct

struct linked_list {
   struct *linked_list prev, next;


>
> Martin
>
>
>

Fwd: Fwd: R.F.C. Should we abandon User-land probes?

[James Dickens]

oops send prematurely

---------- Forwarded message ----------
From: James Dickens <jamesd.wi@gmail.com>
Date: Oct 20, 2005 3:18 PM
Subject: Re: Fwd: R.F.C. Should we abandon User-land probes?
To: Martin Hunt <hunt@redhat.com>
Cc: "systemtap@sources.redhat.com" <systemtap@sources.redhat.com>


On 10/20/05, Martin Hunt <hunt@redhat.com> wrote:
> On Thu, 2005-10-20 at 15:06 -0500, James Dickens wrote:
>
> >  yes those work fine in kernel code, since variables to access
> > components of the structs/unions are allready availible for the
> > systemtap code and tapsets, but that is not the case of userland,
> > especially in the case of C++ classes/struct. So the user required to
> > enable guru-mode.
>
> Whatever gave you that idea?

because systemtap doesn't understand struct/union etc. how else would
it know what are the members of the struct if they are only used in
userland.

struct linked_list {
   struct *linked_list prev, next;
   char *mydata;
   struct *myother my;
}

James


>
> Martin
>
>
>

Re: Fwd: Fwd: R.F.C. Should we abandon User-land probes?

[Martin Hunt]

On Thu, 2005-10-20 at 15:20 -0500, James Dickens wrote:
> oops send prematurely
> 
> ---------- Forwarded message ----------
> From: James Dickens <jamesd.wi@gmail.com>
> Date: Oct 20, 2005 3:18 PM
> Subject: Re: Fwd: R.F.C. Should we abandon User-land probes?
> To: Martin Hunt <hunt@redhat.com>
> Cc: "systemtap@sources.redhat.com" <systemtap@sources.redhat.com>
> 
> 
> On 10/20/05, Martin Hunt <hunt@redhat.com> wrote:
> > On Thu, 2005-10-20 at 15:06 -0500, James Dickens wrote:
> >
> > >  yes those work fine in kernel code, since variables to access
> > > components of the structs/unions are allready availible for the
> > > systemtap code and tapsets, but that is not the case of userland,
> > > especially in the case of C++ classes/struct. So the user required to
> > > enable guru-mode.
> >
> > Whatever gave you that idea?
> 
> because systemtap doesn't understand struct/union etc. how else would
> it know what are the members of the struct if they are only used in
> userland.

ELFs and DWARFs???

Re: Fwd: R.F.C. Should we abandon User-land probes?

[Frank Ch. Eigler]

jamesd wrote:

> [...]
> because systemtap doesn't understand struct/union etc. how would it
> know what are the members of the struct
>
> struct linked_list {
>    struct *linked_list prev, next;

There is a germ of truth to something you don't say (a), but said truth
germ is absent in what you do say (b).

(a) Operators for programmatic traversal of link/tree structures have
not yet been defined.  If you don't know what this means, you won't
miss it.

(b) Probes for the user-level programs would rely on the debug info
for those programs, in exactly the same way we use kernel debug info
for kernel-level probes.  So user-level structs and such should be
exactly as navigable as kernel-level ones.


- FChE

Re: R.F.C. Should we abandon User-land probes?

[Richard J Moore]

systemtap-owner@sources.redhat.com wrote on 20/10/2005 19:15:59:

> Hi
>
> Because of Systemtap's language lack of support for structs, unions,
> typedefs, Systemtap ends up just being a counter, couldn't a userland
> app be written to count the number of times a function is called.
>
> The lack of support for those language construct is bad enough for
> kernel probes, it can be worked around with pre-made tapsets, but are
> we going to write custom tapsets for every app every written?
>
> Guru-mode is no solution, do we have to disable all the work the
> Systemtap coders to make Systemtap as safe as possible. Guru-mode can
> never be used in a production system without lots of testing. In the
> end it would be easier to use other methods, to debug the problem.
> Resorting to Guru-mode makes the system unstable. You end up debugging
> your script, instead of debugging the app.
>
> Further more, the chance of having an app pass a bad pointer increases
> dramatically and may even be the reason they are probing the app in
> the first place.  As we all know passing a bad pointer in a userland
> app, crashes the app, but do the same in the kernel we get an oops, or
> the system crashes. You may even write code to handle such events in
> Systemtap but that isn't used in guru-mode.
>
> The only way I see that Systemtap can be useful with userland probes
> is to implement support for structs, unions and typedefs. It would be
> even more helpful if you implement cpp support, so you can include
> header files into scripts.
>

I disagree entirely.

Whether user-mode probes are useful given the current functionality depends
on the purpose to which they are being put. From the perspective of having
to diagnose some hard-to-reproduce load-realted problem I would find the
current functionality essential. If necessary I would objump -S  the user
code in order to determine what to place my probes and what data to
examine. If it helps me debug an obscure but severe problem then I'll take
whatever help I can get.

Don't throw out the baby with the bathwater.

Richard J Moore (LTC, IBM)

> James Dickens