Working on -e trace

[haris iqbal]

On Thu, Feb 18, 2016 at 2:51 PM, haris iqbal <haris.phnx at gmail.com> wrote:
> On Thu, Feb 18, 2016 at 8:07 AM, Dmitry V. Levin <ldv at altlinux.org> wrote:
>> On Wed, Feb 17, 2016 at 04:56:39PM +0530, haris iqbal wrote:
>>> On Sun, Feb 14, 2016 at 5:54 AM, Dmitry V. Levin wrote:
>>> > On Thu, Feb 11, 2016 at 09:04:56PM +0530, haris iqbal wrote:
>> [...]
>>> >> Another thing. If I did not miss any step above then I can start thinking
>>> >> about the new category to be added.
>>> >
>>> > What category seems the most promising so far?
>>>
>>> Ok,  I did a little research to find out the system calls that are
>>> missing a group. And I found some calls that can be made into groups.
>>> They are as follows.
>>>
>>> 1) Timer and Clock type. This group will include all the system calls
>>> that create per-process timers, and the ones that work on clocks.
>>> Example : timer_* and clock_*. May be others also.
>>>
>>> 2) Another one that can be added, which Dmitry suggested in the
>>> beginning was all system calls dealing with uid and gid.
>>>
>>> 3) The last one which I noticed that can be added are the system calls
>>> which deal with scheduler. sched_* system calls.
>>>
>>> NOTE: If there are any suggestions, please feel free to comment. :)
>>
>> There are at least three directions to look for potential syscall groups:
>>
>> - Different syscalls from the same family, e.g. io_*, *xattr, *timer*,
>>   clock_*, sched_*, *uid, *gid, mq_*, NUMA-related (get_mempolicy, mbind,
>>   migrate_pages, move_pages, set_mempolicy), etc.
>
> Well, this is the direction that I took, to find potential new syscall
> groups. And there are a plenty that can be considered. The ones that I
> was particularly interested in (since they are not included in any of
> the groups) are sched_*, *uid and *gid and *timer* and clock_*.
>
>>
>> - Small groups of similar syscalls, often pairs where one syscall is
>>   a predecessor of another, e.g. open/openat and similar *at pairs,
>>   accept/accept4, dup2/dup3, epoll_create/epoll_create1, eventfd/eventfd2,
>>   inotify_init/inotify_init1, pipe/pipe2, pselect/pselect6,
>>   rename/renameat/renameat2, umount/umount2, etc.
>>   On newer architectures older syscalls are not available, so it might be
>>   a good idea from portability PoV.  For example, a group of open-like
>>   syscalls could be used instead of trace=open,openat to do a more
>>   portable tracing across different architectures.
>
> Ok, I feel if we use this way, there will be too less number of
> syscalls in the new group we create. And, if it is too small then
> won't it be easier to trace using the specific name like -e
> trace=pipe, pipe2.
>
> It can though serve the purpose of covering similar syscalls for
> different architectures that will be good for portability.
>
>>
>> - Small groups of syscalls that are almost the same but called
>>   differently between architectures, e.g. newfstatat/fstatat64, or have
>>   very subtle differences, like LFS vs non-LFS editions of syscalls.
>>   In such cases, there is no simple rule to find out the right syscall
>>   name(s) on a given architecture, so having a way to specify, e.g.
>>   all fstatat-like syscalls might be a good idea from portability PoV.
>
> This would need a thorough information of all syscalls of all
> architectures to get it right. I can start working on this by manually
> mapping each syscall of every architecture to the task it performs and
> then checking the intersection of those mappings.
>
>>
>> If we are going to have so many different syscall groups, it's time to
>> think about a naming policy.  I think that all new syscall group names
>> should start with a non-alphanumeric symbol (e.g. "%" or "@") to avoid
>> collisions with syscall names.
>
> That is a good idea. Can't we start with something more simple like
> g_file, which would stand for group of all syscalls related to files.
> Special symbols might make it a little complicated.
>>
>>
>> --
>> ldv
>>
>> ------------------------------------------------------------------------------
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>> _______________________________________________
>> Strace-devel mailing list
>> Strace-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/strace-devel
>>
>
> I would like to start working on the sched_* and the *uid *gid ones.
>
> --
>
> With regards,
>
> Md Haris Iqbal,
> Placement Coordinator, MTech IT
> NITK Surathkal,
> Contact: +91 8861996962

Hello,

A little help is needed here. I could understand that for the -e
option, one uses the combination of sysent_vec[][].sys_flags and the
macros TRACE_FILE and others, which sets the proper flag in qual_vec.
Now that qual_vec is used by qual_flg in the tcb struct (correct me if
something is wrong).

But what I could not find is where those flag is used to print only
the syscalls that are needed (like only file related). I searched and
followed the flow of execution and found trace_syscall_entering()
through trace_syscall() in trace(). There is a function calles
get_scno(), I guess its where this syscall filtering is happening but
not sure. Can someone please point me in the right direction.


NOTE:

1) I am looking at the -e option closely to come up with a POC for the
idea "Fault injection for syscalls".

2) Waiting for a reply for the naming policy so that I can start
working to add the sched_* and the *uid *gid ones to the -e option.


-- 

With regards,

Md Haris Iqbal,
Placement Coordinator, MTech IT
NITK Surathkal,
Contact: +91 8861996962