On Thursday, March 12 2015, Oleg Nesterov wrote:
>> If I understood this discussion correctly (and thanks Andy and Oleg for,
>> *ahem*, dumping all this useful information for us!), GDB will not need
>> modifications in the Linux kernel in this area. In fact, my patch
>> already implements the "i
On Thursday, March 12 2015, Oleg Nesterov wrote:
>> Let's wait until my special_mapping vmops rework lands to do that.
>> I'll dust it off and resubmit it.
>
> OK. Please CC me. Not that I think I can help, just I want to understand
> what you are going to do.
If you think your work will impact t
On Thursday, March 12 2015, Oleg Nesterov wrote:
>> gdb will still need changes, though, right?
>
> This is up to gdb developers. To me, it should simply skip this
> VM_DONTDUMP vma.
If I understood this discussion correctly (and thanks Andy and Oleg for,
*ahem*, dumping all this useful informati
On Friday, January 10 2014, Oleg Nesterov wrote:
> So suppose that gdb does ptrace(PTRACE_SINGLESTEP) and the tracee
> executes the "syscall" insn. What it should report?
[...]
> But what should syscall-exit do? Should it still report SIGSEGV as
> it currently does, or should it report _SYSCALL_EX
On Thursday, January 09 2014, Roland McGrath wrote:
>> I won't argue, but it is not clear to me if this is really useful,
>> given that the debugger can read the regs.
>
> I do see the utility of having a consistent machine-independent way to get
> the syscall number from userspace. But note that
On Monday, January 13 2014, Denys Vlasenko wrote:
> On Mon, Jan 6, 2014 at 11:52 PM, Sergio Durigan Junior
> wrote:
>> The other nice thing that I have implemented is the ability to obtain
>> the syscall number related to the event by using PTRACE_GET_EVENTMSG.
>> Th
On Tuesday, January 07 2014, Oleg Nesterov wrote:
> On 01/06, Sergio Durigan Junior wrote:
>>
>> This patch implements the new PTRACE_EVENT_SYSCALL_{ENTER,EXIT} events
>> for ptrace. The goal is kind of obvious: it lets the tracer to request
>> for notifications when
s and send them to the correct maintainers of each
part. What I'm looking for now is a feedback of my approach. The
really interesting bits are at the bottom of the patch, which deal with
tracehook.h and its friends in order to implement the new ptrace
options.
Comments are welcome. Thanks.
--
Se
8 matches
Mail list logo
