(2014/08/16 10:38), Wang Nan wrote:
> On 2014/8/15 23:23, Masami Hiramatsu wrote:
>> (2014/08/12 13:56), Wang Nan wrote:
>>> +/* Caller must ensure addr & 3 == 0 */
>>> +static int can_optimize(unsigned long paddr)
>>> +{
>>> + return 1;
>>> +}
>>
>> As we have talked on another thread, we'd
On 2014/8/15 23:23, Masami Hiramatsu wrote:
> (2014/08/12 13:56), Wang Nan wrote:
>> +/* Caller must ensure addr & 3 == 0 */
>> +static int can_optimize(unsigned long paddr)
>> +{
>> +return 1;
>> +}
>
> As we have talked on another thread, we'd better filter-out all stack-pushing
>
(2014/08/12 13:56), Wang Nan wrote:
> +/* Caller must ensure addr & 3 == 0 */
> +static int can_optimize(unsigned long paddr)
> +{
> + return 1;
> +}
As we have talked on another thread, we'd better filter-out all stack-pushing
instructions here, since (as you said) that will corrupt pt_regs
(2014/08/12 13:56), Wang Nan wrote:
+/* Caller must ensure addr 3 == 0 */
+static int can_optimize(unsigned long paddr)
+{
+ return 1;
+}
As we have talked on another thread, we'd better filter-out all stack-pushing
instructions here, since (as you said) that will corrupt pt_regs on the
On 2014/8/15 23:23, Masami Hiramatsu wrote:
(2014/08/12 13:56), Wang Nan wrote:
+/* Caller must ensure addr 3 == 0 */
+static int can_optimize(unsigned long paddr)
+{
+return 1;
+}
As we have talked on another thread, we'd better filter-out all stack-pushing
instructions here, since
(2014/08/16 10:38), Wang Nan wrote:
On 2014/8/15 23:23, Masami Hiramatsu wrote:
(2014/08/12 13:56), Wang Nan wrote:
+/* Caller must ensure addr 3 == 0 */
+static int can_optimize(unsigned long paddr)
+{
+ return 1;
+}
As we have talked on another thread, we'd better filter-out all
(2014/08/12 22:03), Wang Nan wrote:
> Hi Masami and everyone,
>
> When checking my code I found a problem: if we replace a stack operatinon
> instruction,
> it is possible that the emulate execution of such instruction destroy the
> stack used
> by kprobeopt:
>
>> +
>> +asm (
>> +
Hi Masami and everyone,
When checking my code I found a problem: if we replace a stack operatinon
instruction,
it is possible that the emulate execution of such instruction destroy the stack
used
by kprobeopt:
> +
> +asm (
> + ".global optprobe_template_entry\n"
> +
Hi Masami and everyone,
When checking my code I found a problem: if we replace a stack operatinon
instruction,
it is possible that the emulate execution of such instruction destroy the stack
used
by kprobeopt:
+
+asm (
+ .global optprobe_template_entry\n
+
(2014/08/12 22:03), Wang Nan wrote:
Hi Masami and everyone,
When checking my code I found a problem: if we replace a stack operatinon
instruction,
it is possible that the emulate execution of such instruction destroy the
stack used
by kprobeopt:
+
+asm (
+.global
This patch introduce kprobeopt for ARM 32.
Limitations:
- Currently only kernel compiled with ARM ISA is supported.
- Offset between probe point and optinsn slot must not larger than
32MiB. Masami Hiramatsu suggests replacing 2 words, it will make
things complex. Futher patch can make
This patch introduce kprobeopt for ARM 32.
Limitations:
- Currently only kernel compiled with ARM ISA is supported.
- Offset between probe point and optinsn slot must not larger than
32MiB. Masami Hiramatsu suggests replacing 2 words, it will make
things complex. Futher patch can make
12 matches
Mail list logo
