This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: Syscall tracing
>>>>> "Roland" == Roland McGrath <roland@redhat.com> writes:
[...]
Thanks for this.
Roland> For the consideration of syscalls, I'd like to take it just up to the
Roland> point of establishing the #1-#5 info items in DWARF or DWARF-esque form,
Roland> and then draw a line under it. Beyond that, there is just the general
Roland> discussion on sexy information display/inspection. When everything new
Roland> and pretty exists, syscall handling has just some simple choices on UI
Roland> tie-in left.
I've been thinking about pretty-printing as being a type-specific
thing -- that is, the C++ cases of having some class or template with
a printer which is always used to display objects of that type.
With syscalls, I think the printer could not really work this way.
(This is not a major problem -- just new information.) For all I know
we will want specialized printers in other situations too -- for
instance out parameters in other functions, and not just syscalls.
Also, I'm wondering about ioctl, where the last argument can take many
different forms. To do an excellent, strace-esque job of display,
this information would have to come from the kernel as well (IMO), in
a usable form ... "request X" corresponds to "struct Y *" or whatever.
Oh -- I found 'man ioctl_list' tonight. Problem solved :)
Maybe there are other cases? I don't know offhand.
There are some rough analogs to this in typical user programs, I think.
Our basic plan in these situations is to require the maintainers of
these programs to maintain the specialized debug code as well.
Tom