This is the mail archive of the 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]

'catch syscall' Status

Hello everybody,

As some of you may know, I am working with Thiago and the GDB team here
in LTC Brazil. Yesterday, Thiago and I wrote this piece of text
explaining in a few words what's the status of the 'catch syscall'
feature (to be implemented). Hope you enjoy it.

Feature: 'catch syscall'

There is a prototype of this already implemented [1], but unfortunately
the submitter seems to have disappeared in the dust.

The work can be divided in two basic parts:

1. Get notification when the inferior enters and/or leaves a syscall
2. Parse syscall arguments and return values

For no 1, basically what we need to do is use the PTRACE_SYSCALL option
from ptrace(2). At this time we are not considering how to get the
arguments from the call. Should not be a difficult task, about a couple
of weeks.

No 2 is still the subject of discussion. The current consensus seems to
be that the kernel should provide DWARF debuginfo describing the types
and ABI layout used by the syscalls. There are two suggested approaches.
Daniel's is to augment DWARF with annotations about the semantics of
types used in arguments and return values [2], and Roland's is to use
regular DWARF and then have a pretty-printer which knows how to display
the arguments and return values [3].

If there is already existing kernel debuginfo covering syscalls and
types related to them, it shouldn't be hard to follow Roland's
suggestion after the pretty-printer task is done. Something between a
couple of weeks and one month, I think.



Sérgio Durigan Júnior
Linux on Power Toolchain - Software Engineer
Linux Technology Center - LTC
IBM Brazil

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