[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ptp-dev] debug output question
|
Greg -
... well, I didn't think, I just jump onto it.
thanks for the info, I will take a closer look at it.
A unrelated question on GDB/MI interface: suppose the target program has
a output stream, denoted by @, but as the following interaction shows,
"res = 6" stdio from sample program doesn't have @ prefix ... why?
(gdb)
-exec-continue
^running
(gdb)
res = 6
*stopped,reason="exited-normally"
(gdb)
I also tried MI API to see if I get anything through target callback,
and again, nothing comes out of it ... am I missing something here?
void
target_callback(char *str)
{
printf("target> %s\n", str);
}
int main()
sess = MISessionNew();
if (MISessionStartLocal(sess, "/home/fwang2/gdb/test") < 0) {
fprintf(stderr, "%s", MIGetErrorStr());
return 1;
}
MISessionRegisterTargetCallback(sess, target_callback);
cmd = MICommandNew("run", MIResultRecordDONE);
MICommandRegisterCallback(cmd, cmd_callback, sess);
sendcmd_wait(sess, cmd);
...
Greg Watson wrote:
Sorry, too much happening all at once....
You thought this was going to be easy, right?
1. Take a look at line 151 of
org.eclipse.ptp.debug.sdm/src/mi/MISession.c. The -tty argument tells
gdb to forward I/O from the program being debugged to the device, in
this case /dev/null. You'll need to set up a pseudo terminal and forward
the I/O to this instead. Pseudo terminals come in pairs: a master and a
slave. Whatever is sent to the master can be read from the slave and
vice versa. So you will need to change MISession.c do the following:
a) Create a pseudo terminal pair.
b) Open the master save the file descriptor. You'll probably want to
save it in the MISession structure.
c) Pass the slave side of the pseudo terminal to gdb using the -tty
argument.
d) Modify MISessionProgress() so that it checks this file descriptor and
reads from it if there is anything available.
e) If you do read something, create an MITargetStreamOutput record using
NewMITargetStreamOutput() and add the output to this, then call
DoOOBStreamCallbacks() to send the record.
f) For the moment, I suggest modifying AsyncCallback in gdbmi_backend.c
to check for this event and just print the output to stdout (see
AsyncStop for an example of how to check the event type). This *should*
get picked up by ORTE and forwarded back to Eclipse. We can work out how
to do it properly later.
Note: there are at least two ways to create psuedo terminals. The BSD
way and the SYSV way. I think Linux supports both. See the wikipedia
entry for a description. I should also be able to dig up some sample
code if you'd like.
2) No. You can attach gdb to the running process, but it's tricky to
know which one. I usually just run the whole SDM on my local machine and
observe stdout.
Let me know if you need more info.
Greg
On Oct 2, 2007, at 11:28 AM, Feiyi Wang wrote:
On my 2nd question, both orte proxy and sdm can be attached by having
appropriate debug configuration. However, how gdb/mi layer handle
program stdio is not clear to me yet - any help?
Feiyi
Feiyi Wang wrote:
Greg -
I have made changes to debug_app_job_state_callback to register IO
forwarding callback, but I didn't see output being sent back to the
front. So the next step of investigation would be to check if the
backend (gdb/mi) is send the message back if I understand this
correct. Two questions: (1) can you provide any pointers on where I
should be looking at (2) is there any way I could set up eclipse
debugger to hook into orte proxy and sdm process?
Thanks
Feiyi
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev