Re: Regarding systemtap support for AArch64

[Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>]

(2013/10/04 12:24), Sandeepa Prabhu wrote:
>>>>  - Is it really need to use spinlock to protect break_hook?
>>> Any cpu can remove breakpoint hooks right, and traversal happen in
>>> debug exception context so mutex are not safe (can sleep/schedule out)
>>> in debug exception.
>>
>> I don't think we need to remove the breakpoint hooks after starting
>> up the kernel. If we use the spinlock there, we'll pay a big cost
>> because of the lock contention.
> Not in kprobes. But kgdb can remove breakpoint handler and use same
> API. or atleast while providing an api we should not assume race
> cannot happen right?

In that case, we'd better add a wrapper handler for kgdb so that
the list isn't updated even if the kgdb removes its handler.

> And there wont be much lock contention, i'ts only if the debug
> framework (like kgdb) is wrapping-up, not is normal use-case.

Hmm, it seems that the spinlock is locked while handling a breakpoint.
This will cause a bad performance issue when we put many kprobes
on SMP system.

[...]
>>>>  - probes-*.c is not good name for the simulator. those should have
>>>>    better name.
>>> May be decode-arm64.c? Originally I had decode-* but the logic is
>>> limited to kprobes and uprobes only so renamed that way.  Other cases
>>> like jump_labels, use different decoding, and may not share same code.
>>
>> The decoding table will be different from other usecase, but I think
>> simulator code can be shared (and must be). It may just get the address,
>> instruction, and registers, not the kprobe.
> When we wrote at Linaro, our plan was to share simulation calls
> between kprobes and uprobes, and planned to use 'struct kprobes' for
> both the frameworks, this is how it was done on "arch/arm/kernel/"
> effectively.

Uh, I should review arm32 again...

> If more frameworks can use it (as it seems) I change it to accept
> opcode, pc value and saved pt_regs and avoid kprobe struct altogether.
> Also, we are starting on uprobes at Linaro, so it won't be too long
> before we start thinking about that too ;-)

Since kprobes data structure includes many information which is not related
to the simulation, I'd like to keep it away from that.

[...]
>>> Masami,
>>> Couple of questions:
>>> 1. My changes reside in arm/arm64 only right now, does it make sense
>>> to publish on LKML so that core kprobes developers can review?
>>
>> Of course, it is always helpful for us :)
>>
>>> 2. Wanted to change sample/kprobes/kprobe_example.c to check for the
>>> missing case of ARM & ARM64 and print the relevant info. Can this
>>> change be as part of same series (if going on LKML)?
>>
>> Yeah, it is better to update it within the series.
> OK, I will do that, and CC LKML from v2.

thanks :)

>>> Thanks a lot for your review, I would also need help on validation for
>>> my work, please let me know if our repo holds good for systemtap
>>> validation. I am interested in using fedora on v8 model, please
>>> provide me some instructions to get the packages.
>>
>> Thank you !
> 
> Question:
> I am working on v2 patchset based on comments, for next week to post,
> do you have basic aarch64 setup (fast-model/hardware), ARM v8-ARM etc?
> I mean, how about sharing some efforts with me(Linaro) going further?

Yeah, I have a foundation-model simulator, I just need to set it up.

> Most work shall go through LAKML so you may have to subscribe to that
> ;),  but do you mind working on Linaro hosted public git ? we can lay
> out a plan then. After kprobes, we have much work on uprobes in queue
> (both 32-bit and 64-bit user-space) and your insights help us, since
> you are one of the maintainers of both subsystems.

Oh, OK. I'll subscribe it, and, yeah, linaro public git should be
better place to work with :)

Thank you,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com