[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ptp-dev] Questions about debugger support
|
On Feb 13, 2008, at 9:45 AM, Dave Wootton wrote:
Greg
I took a quick look at what happens when I try to run a PE
application in
a debug session. At this point I'm just trying to understand what
happens
with the run command so I can begin to understand how a debugger
works.
I see several parameters that are present when running in debug
mode. It's
pretty obvious debugExecPath and debugExecName are components of the
top
level debugger executable path name and debugArgs are parameters to
the
debuger. I suspect that you intend that execPath be passed to the
debugger
as the name of the executable to debug. I'm not sure what happens with
debugStopInMain and launchedByPTP. It also looks like the debug=true
is
intended to be a flag to the proxy that tells me that a debugger is
to be
launched instead of an application.
I'm still working out exactly what parameters make sense, but here's
the current list (from
org.eclipse.ptp.core.elements.attributes.JobAttributes):
Job launch:
console - user has requested that output be displayed in console window
env - a list of environment variables that should be present when the
job is launched (probably should have a replace/add flag as well)
execName - name of the executable to launch
execPath - path to the executable location. Appending the execName to
the execPath provides a path to the executable.
ioForwarding - intended to be used to specify the type of I/O
forwarding. Not implemented yet.
launchedByPTP - flag to indicate the job was launched by PTP. This is
to allow the proxy to indicate to Eclipse that a job was launched by
PTP. Since jobs could have be launched by other means, this will let
PTP treat these jobs as special. For example, a debug job that gets
submitted by PTP but doesn't run during the current session could be
flagged this way. When a new session is started and the job launches,
PTP could still allow the debugger to connect and start a debug session.
jobNumProcs - number of processes to launch
progArgs - list of arguments to the program
queueId - name of queue for job submission
jobState - status of the job
jobSubId - temporary ID for job submission
workingDir - current working directory for job exection
Debug:
debug - flag to indicate to proxy that this is a debug launch
debugArgs - any arguments that need to be supplied to the debug server
debugExecName - name of the debug server executable
debugExecPath - path to debug server executable location. Appending
the debugExecName to the debugExecPath provides a path to the server
executable.
debugStopInMain - flag to debug server to indicate the initial suspend
location should be the main() entry point.
I think debugging would fail pretty quickly once the top level debug
executable is started since we aren't doing anything about the per-
task
setup of environment variables that PE requires in order to run a
parallel
application or any of the other setup that the application needs in
order
to run.
I notice that poe sets a bunch of environment variables, but three
stand out as being important for MPI initialization: MP_PARTITION,
MP_CHILD, and MP_CHILD_INET_ADDR. It would be very easy to add these
to the SDM so they are passed to the job being debugged. The problem
is that the SDM and the application are both MPI programs, so we would
really need some way to allocate an extra partition that the
application could use. Do you know if there is any way of doing this?
Greg
