Re: Support pipes in the run command.

Re: Support pipes in the run command.

[Thiago Jung Bauermann]

El jue, 05-03-2009 a las 18:59 +0200, Oguz Kayral escribió:
> >> Thiago > 3. Support pipes in the run command (this may be too small for a GSoC);
> >>
> >> I'm planning to spend some nights on this before GSoC starts.
> 
> > Nice. Let me know if you need help. I think you won't have to mess with
> > ugly parts of GDB internals, so it's a good feature to start.
>
> Tom Tromey told me that redirecting output was already implemented in
> gdb. So what were you meaning in this e-mail?

We do have redirection, but not pipe support, i.e., having output come
from another command, not a file. But perhaps what he means is that
since we have redirection, lack of pipe support can be worked around by
redirecting the output of the first command in the pipe to a file, and
then debug your program reading from that file.

Still, IMHO it's better to directly support this use case. I've seen
people ask about it in #gdb.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

Re: Support pipes in the run command.

[Tom Tromey]

>>>>> "Thiago" == Thiago Jung Bauermann <bauerman@br.ibm.com> writes:

>> Tom Tromey told me that redirecting output was already implemented in
>> gdb. So what were you meaning in this e-mail?

Thiago> We do have redirection, but not pipe support, i.e., having output come
Thiago> from another command, not a file. But perhaps what he means is that
Thiago> since we have redirection, lack of pipe support can be worked around by
Thiago> redirecting the output of the first command in the pipe to a file, and
Thiago> then debug your program reading from that file.

We had a small miscommunication, because on irc he pointed me at an
old thread about redirecting gdb's output -- for which we have
"set logging".

With multiple inferiors I think we could extend the run command in a
few ways.  First, let it support multiple commands in pipeline, as you
suggest.  Second, give gdb a way to run a shell script and have it
trace the shell and all child processes.  (I've long wanted this so I
can just run the wrapper scripts that libtool generates in a build
tree...)

I have little idea whether either of these is doable in a summer.

Tom