[lkml]   [2012]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 02/16] perf: Unified API to record selective sets of arch registers
On Mon, Apr 23, 2012 at 12:33:50PM +0200, Jiri Olsa wrote:
> On Mon, Apr 23, 2012 at 12:10:57PM +0200, Stephane Eranian wrote:
> > On Tue, Apr 17, 2012 at 1:17 PM, Jiri Olsa <> wrote:


> > How are you going to deal with 32-bit binaries sampled on a 64-bit system?
> I dont have the solution right now... but seems like compat tasks need more
> thinking even before go ahead with this patchset.. since it's going affect
> the perf_event_attr and could bite us in future.
got more info on the compat task unwind

- for 32 bit task running under 64 bit env. the 64 bits user
registers values are stored on kernel stack when entering
the kernel via exception or interrupt, like for native
64 bit task

So I think we can keep the current interface as far as
compat tasks are concerned, since we will get 64 bits
registers all the time anyway.

The place that will take care of compat task unwind
is the post processing unwind.

For each processed sample we:
- get the sample and translate IP into MAP and DSO
- read DSO ELF class and figure out wether we deal with
64 or 32 bit task
- run libunwind interface with proper task class info,
which gets us to next bullet:

- 64 bit libunwind does not support unwind of 32 bit tasks ;)
so unless that change, I can see just one hacky way of doing
this via 32 bit libunwind being loaded in separate 32 bit
process and doing remote unwind for us..

I'll try to follow on this to see if there'd be some better
libunwind interface solution.. but thats quite longterm ;)

As for the sample registers interface.

Currently we have:

u64 user_sample_regs
- if != 0 we provide the user registers with mask specified
by its value

- it will stay for compat tasks as well
- we could use PERF_SAMPLE_USER_REGS sample type instead of the != 0
check to be more consistent, but that would eat up one sample bit

In some previous email you suggested some generic interface like

attr->sample_type |= PERF_SAMPLE_REGS
attr->sample_regs = EAX | EBX | EDI | ESI |.....
attr->sample_reg_mode = { INTR, PRECISE, USER }

I think we can have something like:

attr->sample_type |= PERF_SAMPLE_REGS
attr->sample_reg_mode = { INTR, PRECISE, USER }

but in case we want eg both USER and INTR modes together then we still
need to have:

u64 user_sample_regs
u64 intr_sample_regs

for the register modes mask definition. Some mode combinations might be
useless, but I think this could work.. we could always customize our
needs with new mode ;)

I'll start to work on this unless I hear some screaming ;)

thoughts? ;)

thanks and sorry for long email,

 \ /
  Last update: 2012-04-26 18:17    [W:0.062 / U:12.552 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site