This is the mail archive of the
mailing list for the Archer project.
'catch syscall' Status
- From: Sérgio Durigan Júnior <sergiodj at linux dot vnet dot ibm dot com>
- To: Project Archer <archer at sourceware dot org>
- Date: Wed, 06 Aug 2008 11:41:13 -0300
- Subject: 'catch syscall' Status
- Organization: LTC - IBM
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 , 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
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 , and Roland's is to use
regular DWARF and then have a pretty-printer which knows how to display
the arguments and return values .
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