Look at the man page, you should set the type to PERF_TYPE_TRACEPOINT
and set the config to the event id.

On my system, sys_enter_open event id is 455

$ sudo cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_open/id
455

Add PERF_SAMPLE_RAW to the sample_type.

BTW
You can compile the tar.gz I sent and echo JSON in the attr format to
it, it'll print back perf data in json format. Easier to experiment
with perf_event_open API than writing a C program.

For example

$ make
$ sudo ./perf2 <<EOF
{
  "attr": {
    "sample_type": [
      "PERF_SAMPLE_IP",
      "PERF_SAMPLE_RAW"
    ],
    "wakeup_events": 1,
    "config": 455,
    "sample_period": 1,
    "type": "PERF_TYPE_TRACEPOINT"
  }
}
EOF
{"type":"PERF_RECORD_SAMPLE","misc":"PERF_RECORD_MISC_USER","sample":{"ip":"7f4f3625263d","data":[-57,1,0,0,7,11,0,0,2,0,0,0,0,0,0,0,-32,101,75,22,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]}}
{"type":"PERF_RECORD_SAMPLE","misc":"PERF_RECORD_MISC_USER","sample":{"ip":"7f4f3625263d","data":[-57,1,0,0,7,11,0,0,2,0,0,0,0,0,0,0,-64,112,75,22,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]}}
{"type":"PERF_RECORD_SAMPLE","misc":"PERF_RECORD_MISC_USER","sample":{"ip":"7f4f3625263d","data":[-57,1,0,0,7,11,0,0,2,0,0,0,0,0,0,0,-112,70,75,22,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]}}
{"type":"PERF_RECORD_SAMPLE","misc":"PERF_RECORD_MISC_USER","sample":{"ip":"7f4f3625263d","data":[-57,1,0,0,7,11,0,0,2,0,0,0,0,0,0,0,-32,70,75,22,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]}}
{"type":"PERF_RECORD_SAMPLE","misc":"PERF_RECORD_MISC_USER","sample":{"ip":"7f4f3625263d","data":[-57,1,0,0,7,11,0,0,2,0,0,0,0,0,0,0,0,-99,26,-19,-1,127,0,0,0,0,0,0,0,0,0,0,-74,1,0,0,0,0,0,0,0,0,0,0]}}
...

What is the raw data? Depends on the event. For sys_enter/exit it is
struct syscall_trace_enter/exit.

http://osxr.org/linux/source/kernel/trace/trace.h#0095
struct trace_entry {
     unsigned short      type;
     unsigned char       flags;
     unsigned char       preempt_count;
     int         pid;
};
struct syscall_trace_enter {
    struct trace_entry  ent;
    int         nr;
    unsigned long       args[];
};

How did I know that? I followed the kernel logic here:

http://osxr.org/linux/source/kernel/trace/trace_syscalls.c#0636
static void perf_syscall_exit(void *ignore, struct pt_regs *regs, long ret)
{
...
rec = (struct syscall_trace_exit *)perf_trace_buf_prepare(size, ...);
...
}

Note that indeed after short+char+char+int we have 2, the open syscall
number in all event's raw data.

On Tue, Mar 31, 2015 at 6:22 PM, sahil aggarwal <sahil.ag...@gmail.com> wrote:
> Actually i need most of the sampling around PERF_TYPE_TRACEPOINT,
> so if i enable tracepoint "syscalls/sys_enter_open/" what will be the "type"
> field in perf_event_header.? And, the the record struct will be same as given
> in "syscalls/sys_enter_open/format" .?
>
> Thanks
>
> On 31 March 2015 at 20:40, sahil aggarwal <sahil.ag...@gmail.com> wrote:
>> Yeah that was clear enough.
>> Thanks a lot. Your code is of great help.
>>
>> Regards
>> Sahil
>>
>> On 31 March 2015 at 19:45, Elazar Leibovich
>> <elazar.leibov...@ravellosystems.com> wrote:
>>> I wanted to ensure the user always see contiguous array of data from
>>> the ring buffer.
>>>
>>> The last piece of data, say "abcde" could wrap around in the ring
>>> buffer and appear like:
>>>
>>> [de...                 ...abc]
>>>
>>> I wanted the user to see a contigious array of the form [abcde].
>>>
>>> So in the case I'm having input that wrap around, I'll simply copy it
>>> to the first buffer
>>>
>>> [wrap_buffer][de..                 ...abc]
>>> would become
>>> [               abc][de...               ...abc]
>>>
>>> And then I'll the user pointer to the leftmost "a", and he'll see
>>> "abcde" without knowing he's handling a ring buffer.
>>>
>>> Let me know if I was clear enough.
>>>
>>> On Tue, Mar 31, 2015 at 2:18 PM, sahil aggarwal <sahil.ag...@gmail.com> 
>>> wrote:
>>>>
>>>> Hi Elazar
>>>>
>>>> Can you help me understand why you have used
>>>> mmap_pages->wrap_base.? And, instead of allocating
>>>> (2^n)+1 pages you allocate (2^n)+2 pages, why so.?
>>>> wrap_base points to (2^n)+2 pages and base points to
>>>> (2^n)+1 pages, what is use of wrap_base.? I tried reading
>>>> perf source too, there it seems they use (2^n)+1 pages only.
>>>>
>>>>
>>>> Thanks
>>>> Regards
> --
> To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to