Re: patches to actually use markers?

* Frank Ch. Eigler ([email protected]) wrote:
> Mathieu Desnoyers <[email protected]> writes:
> 
> > [...]
> >>   trace_mark(kernel_arch_syscall_entry, "syscall_id %d ip #p%ld",
> >> 			(int)regs->orig_eax, instruction_pointer(regs));
> >> [...]
> >> For systemtap use, we'd like to have more information than that.  On
> >> syscall entry, we'd like be able to get the arguments, [...]
> >
> > Well, the approach taken was to instrument each important system call in
> > the syscall specific function to be able to actually know what type of
> > information to record. For instance, if ebx points to a string, the
> > pointer is not very useful, but the string is.
> 
> How would this syscall specific function get ebx or the string,
> without ebx (or regs) being passed as marker arguments?
> 
That's the idea : in the syscall specific function (not in
syscall_trace()), we add another marker that takes the syscall specific
arguments as parameter. I think we use the same approach there.

What I was saying is that we can't extract the string from
syscall_trace() because we have no idea it is a string.


> For systemtap's purposes, we're prepared to have per-systemcall logic
> to decode arguments further, in particular to extract user-space
> strings.  But we need to know where to look for them!
> 
> 
> > You have a good point for the syscall exit instrumentation : adding the
> > return value is trivial and would be very useful.
> 
> (And an errno code if it's separate.)
> 

AFAIK, the errno code is generated by the userspace libraries using the
return value of the syscall, so it would be the same.

Mathieu

> 
> - FChE

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68