how to redirect output of sub program in target extended-remote

how to redirect output of sub program in target extended-remote

[Amker.Cheng]

Hi,
I'm debugging through a remote stub like:
> target extended-remote | stub_program
everything goes ok, but the only problem is that the outputs of
stub_program go into the same terminal of gdb.
Is there any method to redirect the output of stub_program in this case?
BTW, I could not execute stub_program in another console due to the
stub_program itself, so it has to be issued in gdb command line
interface.

Thanks very much

--
Best Regards.

Re: how to redirect output of sub program in target extended-remote

[Jan Kratochvil]

On Sun, 17 Apr 2011 10:06:38 +0200, Amker.Cheng wrote:
> > target extended-remote | stub_program
> everything goes ok, but the only problem is that the outputs of
> stub_program go into the same terminal of gdb.
> Is there any method to redirect the output of stub_program in this case?

(gdb) target extended-remote | stub_program 2>/tmp/file

Or I do not understand the question.


Regards,
Jan

Re: how to redirect output of sub program in target extended-remote

[Amker.Cheng]

>
> (gdb) target extended-remote | stub_program 2>/tmp/file
>
> Or I do not understand the question.

Thanks for replying. I wonder whether '2' in your command stands for
stderr as in shell command line?
when I typed following command:
(gdb) target extended-remote | stub_program 1>/tmp/file
the GDB always failed the connect with message:
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response

while your command ran successfully.

I did not understand the pipe in gdb command line well and did not
find any doc on it. So could you point out some doc and let me learn
it.
Thanks very much.

-- 
Best Regards.

Re: how to redirect output of sub program in target extended-remote

[Jan Kratochvil]

On Sun, 17 Apr 2011 16:09:39 +0200, Amker.Cheng wrote:
> I wonder whether '2' in your command stands for stderr as in shell command
> line?

Yes.


> when I typed following command:
> (gdb) target extended-remote | stub_program 1>/tmp/file
> the GDB always failed the connect with message:
> Ignoring packet error, continuing...
> warning: unrecognized item "timeout" in "qSupported" response

$ info '(gdb)Connecting'
`target remote | COMMAND'
	it should expect remote protocol packets on its standard input, and
	send replies on its standard output.

Therefore 1>/tmp/file is the same as >/tmp/file and this way no gdbserver
packets can be received by GDB.


> while your command ran successfully.

STDERR (2) is not used for gdbserver communication, only STDIN (0)
and STDOUT (1).

If stub_program outputs anything to stdout on its own it (a) cannot be visible
on the screen and (b) it is corrupting the gdbserver protocol although the
gdbserver protocol is resistant against such extraneous data.


> I did not understand the pipe in gdb command line well and did not
> find any doc on it. So could you point out some doc and let me learn
> it.

This is normal shell processing, see `man bash'.


Regards,
Jan

Re: how to redirect output of sub program in target extended-remote

[Amker.Cheng]

On Sun, Apr 17, 2011 at 11:38 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Sun, 17 Apr 2011 16:09:39 +0200, Amker.Cheng wrote:
>> I wonder whether '2' in your command stands for stderr as in shell command
>> line?
>
> Yes.
>
>
>> when I typed following command:
>> (gdb) target extended-remote | stub_program 1>/tmp/file
>> the GDB always failed the connect with message:
>> Ignoring packet error, continuing...
>> warning: unrecognized item "timeout" in "qSupported" response
>
> $ info '(gdb)Connecting'
> `target remote | COMMAND'
>        it should expect remote protocol packets on its standard input, and
>        send replies on its standard output.
>
> Therefore 1>/tmp/file is the same as >/tmp/file and this way no gdbserver
> packets can be received by GDB.
>
>
>> while your command ran successfully.
>
> STDERR (2) is not used for gdbserver communication, only STDIN (0)
> and STDOUT (1).
>
> If stub_program outputs anything to stdout on its own it (a) cannot be visible
> on the screen and (b) it is corrupting the gdbserver protocol although the
> gdbserver protocol is resistant against such extraneous data.
>
>
>> I did not understand the pipe in gdb command line well and did not
>> find any doc on it. So could you point out some doc and let me learn
>> it.
>
> This is normal shell processing, see `man bash'.

Thanks Jan.

-- 
Best Regards.