This is the mail archive of the archer@sourceware.org mailing list for the Archer project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]