[SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-0.9-168-gdcaa1a6

[jistone@sourceware.org]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "systemtap: system-wide probe/trace tool".

The branch, master has been updated
       via  dcaa1a657cef72dec518f7376b5d856ef8f01076 (commit)
       via  219e62c7eeca850d2898fdbfb6b74719195274a6 (commit)
       via  8df306c4443bd9dd1397bab6cba7f61cb2d88af9 (commit)
      from  fab6ce30772ec0c45f7d5e295a6e09c95971e9f5 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit dcaa1a657cef72dec518f7376b5d856ef8f01076
Author: Josh Stone <jistone@redhat.com>
Date:   Wed Mar 18 20:05:56 2009 -0700

    PR9959: hide tracepoint arguments of unknown type
    
    We always have to know the type name of tracepoint arguments, so we can
    declare the right function callback, but we can suppress access to those
    types which we don't (yet) know how to read.

commit 219e62c7eeca850d2898fdbfb6b74719195274a6
Author: Josh Stone <jistone@redhat.com>
Date:   Wed Mar 18 19:04:54 2009 -0700

    PR9959: improve tracepoint arg type-naming
    
    dwarf_type_name now works with more argument types.  There were
    three cases that I needed to improve:
    
    - For "const struct foo*", the debuginfo has a const-DIE named "foo"
      chained to a struct-DIE named "foo", so we can't assume that seeing a
      name means we're down to the base type.  The recursion now decends
      until it explicitly sees a base_type, typedef, struct, or union.
    
    - For "void*", the debuginfo has a pointer-DIE without any DW_AT_type
      after.  Now I'm just catching that failed lookup and writing in
      "void".
    
    - For "va_list", the debuginfo actually resolves to an internal type
      "struct __va_list_tag*", but that struct has no declaration at the
      source level.  I'm just hacking that exact case to say "va_list"
      instead, but it would be nice to find something cleaner...
    
    We'll probably still have problems if any tracepoint uses a function-
    pointer argument, but so far I've only seen that as a "void*", which we
    now handle ok.

commit 8df306c4443bd9dd1397bab6cba7f61cb2d88af9
Author: Josh Stone <jistone@redhat.com>
Date:   Wed Mar 18 18:51:17 2009 -0700

    Support tracepoints with no arguments
    
    LTTng has a few tracepoints without any arguments, which caused our
    compile to fail, claiming that our entry function was not a declaration.
    This just adds an explicit (void) argument list for that case.

-----------------------------------------------------------------------

Summary of changes:
 tapsets.cxx |   82 ++++++++++++++++++++++++++++++++++++-----------------------
 1 files changed, 50 insertions(+), 32 deletions(-)


hooks/post-receive
--
systemtap: system-wide probe/trace tool