gdbserver stdout/stderr redirection (or tty)

gdbserver stdout/stderr redirection (or tty)

[Cleber Rosa]

Hi all,

Short story:

While I'm aware that gdbserver is not inteded to be a "daemonized" 
version of gdb itself, I wonder if the absence of input/output 
redirection[1] in gdbserver can be considered a limitation/bug and what 
is the interest level in having that limitation/bug addressed.

Long story:

We're working on a test framework that already provides some initial 
integration with GDB[2].

The architecture used is based on gdbserver+gdb (speaking MI). It starts 
a gdbserver per debugged process, and a gdb process to interact with it 
using MI. If an a noteworthy event occurs, it disconnects gdb from the 
gdbserver, and allows the use to connect to the gdbserver.

This architecture was chosen because a very important requirement is 
allowing users to use *regular*, *unmodified* gdb binaries for this 
interaction.

While this architecture works OK, it does not provide one fundamental 
feature: getting the output (and less importantly for now, input) right.

References:

1 - 
https://sourceware.org/gdb/current/onlinedocs/gdb/Input_002fOutput.html#Input_002fOutput
2 - http://avocado-framework.readthedocs.org/en/latest/DebuggingWithGDB.html

Re: gdbserver stdout/stderr redirection (or tty)

[Doug Evans]

On Thu, Oct 2, 2014 at 6:46 AM, Cleber Rosa <crosa@redhat.com> wrote:
> Hi all,
>
> Short story:
>
> While I'm aware that gdbserver is not inteded to be a "daemonized" version
> of gdb itself, I wonder if the absence of input/output redirection[1] in
> gdbserver can be considered a limitation/bug and what is the interest level
> in having that limitation/bug addressed.
>
> Long story:
>
> We're working on a test framework that already provides some initial
> integration with GDB[2].
>
> The architecture used is based on gdbserver+gdb (speaking MI). It starts a
> gdbserver per debugged process, and a gdb process to interact with it using
> MI. If an a noteworthy event occurs, it disconnects gdb from the gdbserver,
> and allows the use to connect to the gdbserver.
>
> This architecture was chosen because a very important requirement is
> allowing users to use *regular*, *unmodified* gdb binaries for this
> interaction.
>
> While this architecture works OK, it does not provide one fundamental
> feature: getting the output (and less importantly for now, input) right.
>
> References:
>
> 1 -
> https://sourceware.org/gdb/current/onlinedocs/gdb/Input_002fOutput.html#Input_002fOutput
> 2 - http://avocado-framework.readthedocs.org/en/latest/DebuggingWithGDB.html

Hi.
I think there is interest in making this work better,
but it would be good to get more details on the capabilities you need.