This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap 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]

Re: Hitachi djprobe mechanism


Mathieu Lacage wrote:
> I have probably missed something here but I would appreciate if you
> could point me to my mistake.

I don't see a mistake, you just added the restriction that actually makes
this a saner discussion: using basic blocks instead of arbitrary jmp
insertions.

> The only reasonable reason why you would see the EIP of an instruction
> somewhere on the stack is because it was pushed there as:
>   - a function argument as a function callback.
>   - the return address of a call statement.
> 
> In both cases, these EIPs represent the start of a basic block which
> means that, if you follow my earlier suggestion of calculating carefully
> the complete basic-block tree of your functions to avoid inserting
> probes at basic-block boundaries, you should be able to always ensure
> that these EIPs stay valid. At worst, if they are used by some piece of
> code, the code will jump back to the old basic-block which will
> immediately jump to its probe because its first instruction is the probe
> jump.

In as far as the insertions do not cross basic-block boundaries, then
this would seem to hold, and it would seem to solve the main issues I
had with this approach. I haven't really looked at the implications of
this entirely, and there may be some corner cases still (like copy_to_
user() and the other CPU-related stuff) but it's certainly a refreshing
take on things.

Clearly then it would become necessary to have a basic block analyzer
that runs at least once prior to inserting any such probes. It would
certainly be interesting to see what the compiler reports in terms of
basic block sizes.

BTW, looking rapidely at your script, it doesn't seem to look for "call".
Maybe someone should try compiling the kernel with -fprofile-arcs and
-ftest-coverage to get the .bb and .bbg files, and run an analysis based
on those files.

Thanks for inserting some sanity to this thread.

Side note: None of this will hold with kernels that have preemption
enabled. And from what I can gather from talking about this with folks
at the OLS, preempt_rt seems on its way in. So in as long as we are
talking about non-preemptable kernels, what you suggest should hold.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546


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