This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Adding systemtap probe points in pthread library(slightly revised again)

> 1) I googled and found the glibc "Contribution checklist", and my patch below is now formatted according to the standard set by it (hopefully, the line wrap-around issues and the spacing issues are all addressed).

Now you just need to learn to line-wrap your email text too. ;-)

> 2) And I think I've fixed an issue related to why I needed to check #if
>    (defined USE_STAP_PROBE) -- in stap-probe.h, when USE_STAP_PROBE is
>    not enabled, it is still defined to STAP_PROBE_ASM (IN_LIB, name,
>    template), and I believe it should be defined to something that
>    nullifies it or to dummy.

Oh, indeed.  I've fixed that in the branch now (rebased, not mergeable).

> 3) I still need to check for "IS_IN_libpthread" because I don't want to
>    have probes fired because of non pthread related activities. And
>    example of this is __libc_fork(), which does not have interactions
>    with the "normal" pthread APIs, but it calls lll_futex_wake() when
>    forking a child. I've read the code in all places that use those
>    synchronization mechanisms, and found that it can be useful to trace
>    synchronizations inside glibc, but it is just that they are not
>    totally related to pthread calls. However, if you think it makes sense
>    to have the probes there as they are useful to the programmers/users
>    in general and not those only interested in pthread, I will just take
>    the #defines out and clean up all places that have #define checks for
>    avoiding the probes polluting the tracing space.

If you have probes in the lowlevellock code at all, then I think it makes
sense to have them in all its incarnations.  Those probes are called
"lll_*" so they are about the low-level internals rather than API-level
pthread calls anyway.  With the macros as they are, they will wind up with
provider "libc" instead of "libpthread", so tracing scripts can distinguish
them that way.

You didn't say anything about the conditionalization of cases other than
lll_* code.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]