Here is the typical way I debug stuff.
>From a shell you need to set some environment variables up since you won't be
launching with the dx script. So start out with:
>setenv DXROOT /usr/local/dx
>setenv DXDATA /usr/local/dx/samples/data
>setenv DXMACROS /usr/local/dx/samples/macros
Now from that shell you're pretty good to go for launching the exec.
>ddd /usr/local/dx/bin_intelnt/dxexec
Now from within ddd, set your breakpoints and then you need to run it with -R
-b
flags. This will display the port in the message window below that the server
is
running on (typically port 1900.)
Now from what you were saying, you don't need to debug the UI. So you can just
launch the ui with
>dx -uionly
Once the UI is running, then you need to go to the connect menu and connect to
the
already running server on port 1900 (the default).
If for some reason you need to debug the UI C++ code, then you can do something
similar to above.
You might want to use dx -echo flag to see what real executables and flags are
being
used.
---- Original Message ----
From: Jack Chang
Date: Tue 11/18/03 14:06
To: David L Thompson
Cc: opendx deveoper network
Subject: Re: [opendx-dev] is there a way to use gdb to trace codes
in /exec/dxmods?
Thanks a lot for your help, David.
I tried the following but was not able to connect the UI to the
running server:
> ddd dxui
..... once it runs, I set up some break points and tehn hit "run" to
start the dx server
> dx -uionly
..... I then try to connect to the existing running server but have no
idea which port I should connect to (the default 1900 does not
work)
Please advise and thank you very much for your help and patience!
Jack
On Tue, 18 Nov 2003, David L Thompson wrote:
> What you are seeing is the separation of the two. The user interface
> communicates
to
> the exec over a socket, thus there is no code in the UI that ever runs to do a
> Isosurface per se, instead the exec tells the UI that it is running and when
> it is
> finished as a separate process. In order to debug with the UI and the exec,
> you
will
> need to start an exec using ddd or gdb, then start a UI (dx -uionly), and
> then go
to
> the connect menu and select connect to running server.
>
> David
>
> ---- Original Message ----
> From: Jack Chang
> Date: Tue 11/18/03 12:46
> To: David L Thompson
> Cc: opendx deveoper network
> Subject: Re: [opendx-dev] is there a way to use gdb to trace codes
> in /exec/dxmods?
>
> Thanks for the suggestion, however, I have already had a -ggdb flag on
> CFLAGS. The strange thing is that if I run "ddd exec", I can see all the
> source files within /exec (includes dxmods) but not uipp (which makes
> sense since dxexec does not use the GUI stuff). However, if I run "ddd
> dxui", I can only see files within the /uipp directories but not the codes
> in the /exec directories (which does not make sense to me since dxui still
> need to access dx kernel defined in /exec), so....
>
> Jack
>
> On Tue, 18 Nov 2003, David L Thompson wrote:
>
> > If you can debug some but not others it just seems that the debug flag
> > wasn't on
> > when you compiled your modules. Drop to src/exec/dxmods, edit the Makefile
> > and
> add -
> > g to CFLAGS. Then make clean, and make.
> >
> > ---- Original Message ----
> > From: Jack Chang
> > Date: Tue 11/18/03 9:13
> > To: opendx deveoper network
> > Subject: [opendx-dev] is there a way to use gdb to trace codes
> > in /exec/dxmods?
> >
> > Hello,
> >
> > I am curious if there is a way to use gdb to trace codes in /exec/dxmods?
> > Is there a simple compilation/linking switch within the makefile which
> > will enable me to do so? I can trace most of the dx codes using the
> > debugger except the stuff within the /exec/dxmods. Please advise and thank
> > you very much for your help!
> >
> > Sicnerely,
> >
> > Jack Chang
> >
> > Pittsburgh Supercomputing Center
> >
> >
> >
>
>
>
