Re: ptrace and pseudoterminals

[Pavel Labath]

On 5 November 2015 at 20:29, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote:
> On 11/05/2015 01:35 PM, Pavel Labath wrote:
>> That said, it seems to me that this could be a generally useful
>> feature. For the test suite, I can insert a sleep (even a large one,
>> to be sure), but this seems like a sub-optimal solution for general
>> debugger operation. E.g., when we want to display all tracee output(*)
>> before we print out the debugger prompt, we don't know if the tracee
>> has written anything, and we would need to sleep always, just in case
>> it has done that.
>
> My comment suggesting re-select()ing was aimed at the test suite only.
>
> For the debugger, I would always mixin new output from the target
> regardless of when it arrived. But feel free to ignore my unsolicited
> design advice :)
;)

>
>
>> This is especially tricky for remote debugging, as
>> the current gdb-remote protocol does not allow sending stdio after the
>> stop notification.
>
> Hmm, I could swear I've seen gdb scrolling away with new output while
> stopped.
That's quite possible if this wasn't a remote session. Gdb shares the
terminal with the tracee, so the order the output comes out really
depends on the internal terminal implementation. In lldb, we create a
new pty for the tracee and control the output forwarding ourselves.

If it was a remote session than I would be very interested in it as I
don't think the remote protocol supports that.

>
>> So, I actually quite like the fsync() idea, but I
>> don't know if this is something that would be generally accepted (?).
>
> Let me think more on this; maybe I can come up with a way to trip it
> within an existing method.

Thanks. I have not seen this occurring since, I contacted you, so it's
not a big priority for me now, but I may revisit it later.

>> A side question: When I replace the pty with a pipe, the data seems to
>> be delivered immediately. Is this something that is guaranteed, or
>> this happens to work only accidentally and could change in the future
>> (e.g. by moving the pipe processing to a kworker process or whatever)?
>
> I would think the existing pipe behavior is more or less guaranteed, since
> pipes are commonly used for process synchronization.
That's good to know, thanks. :)

cheers,
pl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/