Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ptp-dev] debug output question
have this working now ... there is a few minor things to fix (one of them being console if MI DEBUG flag is on, then the stdout messages are being printed twice as I use ReadResponse for getting the response). 

I will open a feature request bug id and have it reviewed.

Thanks,

Feiyi

Greg Watson wrote:


On Oct 5, 2007, at 4:06 PM, Feiyi Wang wrote:
hmm ... the status now is, I have done the pseduo terminal stuff, and keep the master in the parent, slave in the child, and am getting stdout through MI (as shown by MI RECV). It is missing the @ I was expecting, I am guessing it is filtered because I didn't set tty in raw mode, but that is all right. I make the callback directly:
The @ is only added by gdb to the MI target output stream. When using -tty the application output is sent directly to the pseudo terminal. 


if (sess-> target_callback != NULL)
    sess -> target_callback(str);
instead of DoOOBStreamOutput() since the data now is string type and I don't need to construct the MIOutput record again (there might be other implications by not doing that, but for now ...). Target callback is done to stdout the string. However, However, it is not being picked up.
Now, I am looking at debug_app_job_state_callback() to see if I did the right thing - two questions:
(1) in addition to registering IO forwarding, should I check for job state, and invoke sendProcessStateChangeEvent() as needed? as did in job_state_callback() for normal launch?
No. For a debug job, the debugger controls the process state in the UI. This is because states such as SUSPENDED are only known by the debugger. You still have to manage the *job* state however. This is already done in debug_job_state_callback().
(2) job_state_callback do j = find_job(jobid, JOBID_ORTE); to locate job id, I saw two other constants defined JOBID_PTP and JOBID_DEBUG - what are the intended use?
A debug launch actually creates two different ORTE job IDs, the debugger and the application being debugged. However in Eclipse, we are only interested in seeing the application (for state changes, etc.), and we don't want to see the debugger in the runtime UI. The ptp_job structure is used to maintain a mapping between three job IDs: the job ID of the combined debug/application job as known by the UI, the ORTE job ID of the debugger and the ORTE job ID of the application (in the case of non-debug jobs, the debug job ID is -1). When communicating with the UI, the ptp_jobid is always used. When communicating with ORTE, the debug_jobid or orte_jobids are always used. The JOBID_XXX constants are used to look up an internal job structure given the corresponding job ID. So, for example, if you have the ORTE job ID of the debugger, you can find the job by specifying JOBID_DEBUG when calling find_job(). 



Greg
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev

Back to the top