GDB 4.18 was not in patch A. It took some begging to get it 
Actually, the execution window seemed to be working for me with the
original download of RTP. But when I did a “pristine” install of the
new “Patch A” version, I found that execution windows no longer worked.
Interestingly, my “pristine Patch A” system contains gdb 4.17, not
4.18. Hmmm.
In article <96919t$nef$> 1@nntp.qnx.com> >, Graeme Peterson <> gp@qnx.com
wrote:
Igor, please clarify - what was broken by patch A? As far as
I know, the execution window has never worked except with the
procfs interface that you have in 4.18, and that I have brought
forward to 5.0.
You might have seen something on a local machine using pdebug
to imitate a native debug session, because then the target’s devc-pty
happens to be the host’s devc-pty, but this would have been a fluke,
and not a true functioning feature of gdb/pdebug. I am working on it.
GP
Kris Warkentin <> kewarken@qnx.com> > wrote:
Indeed, Graeme is, even as we speak, attempting to do just that. It turns
out that in the QNX specific part of gdb that deals with the pdebug
protocol,
there is a parsing of any redirection symbols (so as to not bugger up the
remote client). So, the simple (and transparent to DDD hopefully) solution
involves parsing out the redirection and letting gdb take turns talking to
the console and the remote execution window. Then everthing will just go
over
the wire to the pdebug process. Of course sometimes these things are
simpler
in the theory than the implementation.
As far as Patch A breaking things, I’m not sure. I was under the impression
that it never worked because it wasn’t implemented. I’ll have to look
further
into it.
Cheers,
Kris
Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:
Well something got crossed just in patch A so it is probably new
io-char. Bun indeed, pdebug-less gdb 4.18 works fine, which however does
not mean problem is solved. You still got to fix whatever was broken by
patch A.
Speaking about remote debugging, how about making host & target to
communicate though qnet?
Then target should have no problems hooking up to /dev/ttypX on host > 
Kris Warkentin wrote:
Hello everyone,
I’ve been looking into what ddd does when it creates an execution window
and here is what I have uncovered:
ddd spawns a shell in a window and then monkeys around with gdb’s
arguments
that will be passed to the program which will be executed. You can see
this
by spawning an execution window from ddd and then typing ‘show args’ at
the
gdb prompt. It tells you that the program arguments will be something
like
“< /dev/ttyp6 > /dev/ttyp6 2>&1” (depending on your shell) where ttyp6 is
the terminal that was just spawned.
Now the main problem we have is that our gdb communicates (by tcp or
serial)
with a pdebug process so when we try to connect things up, things go
wrong.
I didn’t quite see what was happening but when you’re running pdebug on
the
local machine, some wires seem to get crossed somewhere in all the pty/tty
connections and nothing works.
You may not know this but our version of gdb didn’t support interaction
with
a process at all up until now. The light at the end of the tunnel is,
however, that Colin and Graeme’s hard work on the current gdb 5 has
resulted
in a gdb that runs natively (using our own procfs) rather than through
pdebug. What this means is that the execution window works just fine and
behaves exactly as expected. In fact, I just ran vi with full termcap in
an execution window from ddd. So the good news is that gdb 5 now supports
interaction with processes, both locally AND remotely through pdebug.
With good news comes bad however and the bad news is that this will NOT
work
with ddd debugging a target on a remote machine running pdebug. It’s
pretty
obvious why not (process on target says, “You want me to hook up to ttyp6
on
host? No way!”) So the question remains: is this fixable?
When you run gdb in a normal fashion, you, as the user, are hooked up to
stdin/out/err and interact with gdb. As soon as you start running the
program,
however, gdb redirects these streams to the process so that you can
interact
with it instead. So, my thought is that the way to solve this would be to
hook the execution window up to gdb instead of the actual debugged
process,
and have gdb switch back and forth (depending on whether the debugged
process
is running or not) between the terminal and the prompt.
This is just an idea: we don’t support DDD (other than creating a package
for people) and this would require hacking of both gdb and ddd. So, the
short answer is, when we get gdb5 out (should be real soon now…) the
execution window will work on local targets but remote will not likely
work
anytime soon (unless one of you enterprising fellows wants to take a
look…).
In any event, at least you will be able to debug interactive programs
through
the gdb prompt.
Cheers,
m.hinton@computer.org > wrote:
Since installing the QNXRTP update (Patch A), I’ve had difficulty using
a seperate execution window in DDD for the application-under-test
console support. When I select View -Execution WIndow, and then Run DDD
on my program, I immediately receive an error message in the gdb
interaction pane. The gdb interaction looks like this:
(gdb) run
Starting program: a.out
putpkt: write failed: Input/output error.
(gdb)
What makes this even more curious is that the Execution Window appears
normal when created, but once “Run” is attempted, the window title
acquires the gdb output from the “Run” attempt. In other words, after
attempting to run, the DDD Execution Window’s title-bar says:
DDD: a.outputpkt: write failed: Input/output error.
So evidently, DDD (I’m running GNU DDD 3.2.1 (x86-pc-nto-qnx)) is
sending output destined for the gdb interaction pane to the title bar
of the execution window as well. No wonder there’s a problem!
Since Patch A broke Emacs, I’m a little suspicious. Looks like I may
need to download source for DDD and emacs and rebuild both. If you have
any ideas or suggestions, they’d be most welcome!
Thanks,
Mark
–
Kris Warkentin
kewarken@qnx.com
(613)591-0836 x368
“You’re bound to be unhappy if you optimize everything” - Donald Knuth
–
Kris Warkentin
kewarken@qnx.com
(613)591-0836 x368
“You’re bound to be unhappy if you optimize everything” - Donald Knuth