[Bug tapsets/2111] document syscalls tapset

["mcermak at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=2111

Martin Cermak <mcermak at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mcermak at redhat dot com

--- Comment #10 from Martin Cermak <mcermak at redhat dot com> ---
(In reply to Frank Ch. Eigler from comment #5)
> Another important element of finishing this work is to document the syscalls
> tapset in the stapprobes.5 man page.  There is probably no need to
> elaborately
> enumerate all couple of hundred in the man page, but the general conventions
> should be there:
> - what general variables are available ("name", "argstr", ...)
> - what is done for user-space strings, decomposed struct fields

On  Tue  2015-07-21  14:40 , David Smith wrote:                                 
> We've about polished the [nd_]syscall tapsets to a fairly brilliant           
> shine as far as the code goes, but those tapsets aren't documented -             
> PR2111: <https://sourceware.org/bugzilla/show_bug.cgi?id=2111>. Although         
> this sounds a bit boring, there are actually some thinking that needs            
> doing there - like how to handle the nd_syscall probes vs. the syscall           
> probes. We might want to combine the documentation into one set instead          
> of two, but how do you do that cleanly?                                          
>                                                                                  

So this needs parser. Either stap's one, or some external one.                  
So firstly I'll think about how to resuse the former. What's                    
somewhat close to what we need is `stap -L 'syscall.*,nd_syscall.*'`.           
I see two drawbacks here:                                                       

1) This includes conditionals evaluation and thus output is                     
  architecture (and otherwise) specific. I think disabling
  conditionals evaluation might be doable.                                      

2) We don't have correct datatype information. For dwarf                        
   based probes, types do not match due to syscall wrappers, for                
   non-dwarf based syscalls we don't know types at all. Tapset                  
   source could be manually extended to contain type information                
   say, using comments, and then documentation could be                         
   autogenerated. But probably not using stap's internal parser.                
   At least not without significant tweaks.                                     

So using stap parser with conditionals evaluation disabled, collecting
syscalls list, matching syscalls against nd_syscalls and collecting 
convenience variables list per syscall probe (without type information)
might be doable. Thoughts?

-- 
You are receiving this mail because:
You are the assignee for the bug.