This is the mail archive of the
mailing list for the systemtap project.
Re: patches to actually use markers?
* Frank Ch. Eigler (firstname.lastname@example.org) wrote:
> Mathieu Desnoyers <email@example.com> 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.
> - FChE
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68