On 01/14, u3...@miso.sublimeip.com wrote:
>
> So here again is the patch that I need so badly - clearly it fixes a bug
> and harms nobody:
>
> ---
> diff -Naur before/arch/x86/kernel/hw_breakpoint.c
> after/arch/x86/kernel/hw_break
Hi,
> I would not say this is a bug but let me repeat, no need to convince me.
>
> Please feel free to re-send the patch(es) I sent to maintainers. Sorry,
> I can't push these changes into Linus's tree.
So here again is the patch that I need so badly - clearly it fixes a bug
and harms nobody:
--
On 01/10, u3...@miso.sublimeip.com wrote:
>
> Hi Everyone,
>
> > On 01/08, Pedro Alves wrote:
> >>
> >> On 12/04/2012 05:59 PM, Oleg Nesterov wrote:
> >>
> >> > But If we want to allow to trace vsyscall's, hw bp doesn't look very
> >> > nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace th
Hi Everyone,
> On 01/08, Pedro Alves wrote:
>>
>> On 12/04/2012 05:59 PM, Oleg Nesterov wrote:
>>
>> > But If we want to allow to trace vsyscall's, hw bp doesn't look very
>> > nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace them all.
>>
>> Irrespective of the whole syscall tracing iss
On 01/08, Pedro Alves wrote:
>
> On 12/04/2012 05:59 PM, Oleg Nesterov wrote:
>
> > But If we want to allow to trace vsyscall's, hw bp doesn't look very
> > nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace them all.
>
> Irrespective of the whole syscall tracing issue, allowing HW bkpts i
On 12/04/2012 05:59 PM, Oleg Nesterov wrote:
> But If we want to allow to trace vsyscall's, hw bp doesn't look very
> nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace them all.
Irrespective of the whole syscall tracing issue, allowing HW bkpts in
the vsyscall just seems like a bug fix
Dear Jan,
> x86 debug registers are already very scarce. Besides that userland
> applications know they have 4 of them available so it would also break
> them.
If a userland application wants to cheat, then it has no need to bypass
the debug registers: even if there were 4096 of them, covering t
On Sun, 02 Dec 2012 20:30:58 +0100, Oleg Nesterov wrote:
> Yes, that is why I said this needs the new option.
I do not mind new options although personally I do not find them meaningful
for an already deprecated ABI compatibility-only issue.
> If the tracer does PTRACE_SYSCALL the tracee reports
Dear Oleg,
> Yes, I understand, so DR_RW_EXECUTE should probably work. And I even
> sent the patch (untested/uncompiled). But given that even the simple
> bugfix which started this thread was ignored by maintainers, I am
> not sure how we can convince them this change makes sense ;)
Just to confi
On 12/03, u3...@miso.sublimeip.com wrote:
>
> > However. Of course it would be nice to avoid the new option. IMO it
> > would be better to do nothing ;) vsyscall is deprecated, and EMULATE
> > is x86-specific.
>
> The problem is that the current static glibc invokes the vsyscall page,
Yes I know.
Hi Oleg,
> However. Of course it would be nice to avoid the new option. IMO it
> would be better to do nothing ;) vsyscall is deprecated, and EMULATE
> is x86-specific.
The problem is that the current static glibc invokes the vsyscall page,
so statically-linked 3rd-party executables that were dis
Amnon, sorry for delay...
On 11/26, Amnon Shiloh wrote:
>
> > Why do you need to _prevent_, say, sys_gettimeofday()? Why we can't
> > change emulate_vsyscall() to respect PTRACE_SYSCALL and report
> > TRAP_VSYSCALL or PTRACE_EVENT_VSYSCALL as I tried to suggest in
> > http://marc.info/?l=linux-ker
12 matches
Mail list logo
