Guys, I didn't make any snide remark nor did Tim to be fair. My original post queried which process I should attach GDB to. Tim replied saying those were not processes that I had listed but symbols hence the line in question
did you ever have a look at m_pd.h?
I hadn't really and replied to this appropriately. There were no snide remarks intended as far as I am aware.
Still can't get the bugger to set a break point though. GDB was helpfully in that once PD died I could at least the back trace.
Conor
---------------------------------------- From: Hans-Christoph Steiner hans@eds.org Sent: 12 November 2006 23:04 To: Tim Blechmann tim@klingt.org Subject: Re: [PD-dev] gdb listening to PD
On Nov 12, 2006, at 3:29 PM, Tim Blechmann wrote:
On Sun, 2006-11-12 at 10:01 -0500, Hans-Christoph Steiner wrote:
Hmm, never seen that. I just got the "pd" process. Which platform are you on?
did you ever have a look at m_pd.h?
Any reason for this snide comment? Of course I've seen those functions, but never in the context of connecting gdb to the pd process.
How about saying something productive instead?
.hc
.hc
On Nov 11, 2006, at 8:04 PM, Conor J Curran wrote:
Hi, Tonight I was trying to hook up GDB with PD. When attempting to attach to PD, I was presented with the following options. Could anyone tell me which process/es should I connect to?
pd_bang pd_free pd_setloadingabstraction pd_bind pd_free@plt pd_symbol pd_canvasmaker pd_getparentwidget pd_typedmess pd_checkobject pd_init pd_typedmess@plt pd_compiledate pd_list pd_unbind pd_compiletime pd_new pd_version pd_doloadbang pd_new@plt pd_vmess pd_error pd_newest pdfloat_setup pd_fft pd_objectmaker pdint_setup pd_findbyclass pd_pointer pdsymbol_setup pd_float pd_popsym pd_forwardmess pd_pushsym
it's not a list of processes, but a list of symbols ...
hth, tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
All we composers really have to work with is time and sound - and sometimes I'm not even sure about sound. Morton Feldman
------------------------------------------------------------------------
Access to computers should be unlimited and total. - the hacker ethic
On Nov 13, 2006, at 9:59 AM, forwinder wrote:
Still can't get the bugger to set a break point though. GDB was helpfully in that once PD died I could at least the back trace.
...did you compile pd with "-g -O0"? Are you stripping symbols somewhere? What platform are you trying to debug on?
james
Just to add to the fun... I've NEVER been able to get teh debugger to see Pd externals. I can debug Pd itself on linux and Mac OK. The only thing I've found is that, on Mac, it's important to be sure not to 'debug' the GUI process instead of Pd by accident.
cheers Miller
On Mon, Nov 13, 2006 at 11:12:31AM -0500, james tittle wrote:
On Nov 13, 2006, at 9:59 AM, forwinder wrote:
Still can't get the bugger to set a break point though. GDB was helpfully in that once PD died I could at least the back trace.
...did you compile pd with "-g -O0"? Are you stripping symbols somewhere? What platform are you trying to debug on?
james
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On 11/13/06, Miller Puckette mpuckett@imusic1.ucsd.edu wrote:
Just to add to the fun... I've NEVER been able to get teh debugger to see Pd externals. I can debug Pd itself on linux and Mac OK. The only thing I've found is that, on Mac, it's important to be sure not to 'debug' the GUI process instead of Pd by accident.
I debug GEM on Windows and OSX without problems (the MSVC debugger being superior to the OSX gdb based one).
several ways to debug pd externals with gdb:
- crash the external (with asserts) - declare pending breakpoint, that are resolved after the shared library has been loaded - set breakpoint after the dlopen stuff, when the symbols are available - break manually after the external has been loaded and the symbols are available - use the gdb integration into your favorite ide to set breakpoints in source files. (should work with about every decent ide like emacs, eclipse, kdevelop)
tim
On Mon, 2006-11-13 at 09:17 -0800, Miller Puckette wrote:
Just to add to the fun... I've NEVER been able to get teh debugger to see Pd externals. I can debug Pd itself on linux and Mac OK. The only thing I've found is that, on Mac, it's important to be sure not to 'debug' the GUI process instead of Pd by accident.
cheers Miller
On Mon, Nov 13, 2006 at 11:12:31AM -0500, james tittle wrote:
On Nov 13, 2006, at 9:59 AM, forwinder wrote:
Still can't get the bugger to set a break point though. GDB was helpfully in that once PD died I could at least the back trace.
...did you compile pd with "-g -O0"? Are you stripping symbols somewhere? What platform are you trying to debug on?
james
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
Cheat your landlord if you can and must, but do not try to shortchange the Muse. It cannot be done. You can't fake quality any more than you can fake a good meal. William S. Burroughs
Oops, I should have explained more carefully... I can't get GDB to load symbols from externs. So I can trap into GDB when something goes wrong but then can't see anything.
I usually just compile the object I'm debugging into Pd itself to fix this.
cheers M
On Tue, Nov 14, 2006 at 01:25:50PM +0100, Tim Blechmann wrote:
several ways to debug pd externals with gdb:
- crash the external (with asserts)
- declare pending breakpoint, that are resolved after the shared library
has been loaded
- set breakpoint after the dlopen stuff, when the symbols are available
- break manually after the external has been loaded and the symbols are
available
- use the gdb integration into your favorite ide to set breakpoints in
source files. (should work with about every decent ide like emacs, eclipse, kdevelop)
tim
On Mon, 2006-11-13 at 09:17 -0800, Miller Puckette wrote:
Just to add to the fun... I've NEVER been able to get teh debugger to see Pd externals. I can debug Pd itself on linux and Mac OK. The only thing I've found is that, on Mac, it's important to be sure not to 'debug' the GUI process instead of Pd by accident.
cheers Miller
On Mon, Nov 13, 2006 at 11:12:31AM -0500, james tittle wrote:
On Nov 13, 2006, at 9:59 AM, forwinder wrote:
Still can't get the bugger to set a break point though. GDB was helpfully in that once PD died I could at least the back trace.
...did you compile pd with "-g -O0"? Are you stripping symbols somewhere? What platform are you trying to debug on?
james
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
Cheat your landlord if you can and must, but do not try to shortchange the Muse. It cannot be done. You can't fake quality any more than you can fake a good meal. William S. Burroughs
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Wed, 15 Nov 2006, Miller Puckette wrote:
Oops, I should have explained more carefully... I can't get GDB to load symbols from externs. So I can trap into GDB when something goes wrong but then can't see anything.
I don't know what your setup is, but if the externs are really compiled with debugging symbols enabled, you may want to try the following gdb commands:
"help files" "symbol-file"
I vaguely remember having to load a symbol-file manually, but I don't remember why that was nor when it was.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Feel like adding some info as to how to the HOWTO:
http://puredata.org/docs/developer/UsingGdbToDebugPdExternals
.hc
On Nov 14, 2006, at 7:25 AM, Tim Blechmann wrote:
several ways to debug pd externals with gdb:
- crash the external (with asserts)
- declare pending breakpoint, that are resolved after the shared
library has been loaded
- set breakpoint after the dlopen stuff, when the symbols are
available
- break manually after the external has been loaded and the symbols
are available
- use the gdb integration into your favorite ide to set breakpoints in
source files. (should work with about every decent ide like emacs, eclipse, kdevelop)
tim
On Mon, 2006-11-13 at 09:17 -0800, Miller Puckette wrote:
Just to add to the fun... I've NEVER been able to get teh debugger to see Pd externals. I can debug Pd itself on linux and Mac OK. The only thing I've found is that, on Mac, it's important to be sure not to 'debug' the GUI process instead of Pd by accident.
cheers Miller
On Mon, Nov 13, 2006 at 11:12:31AM -0500, james tittle wrote:
On Nov 13, 2006, at 9:59 AM, forwinder wrote:
Still can't get the bugger to set a break point though. GDB was helpfully in that once PD died I could at least the back trace.
...did you compile pd with "-g -O0"? Are you stripping symbols somewhere? What platform are you trying to debug on?
james
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
Cheat your landlord if you can and must, but do not try to shortchange the Muse. It cannot be done. You can't fake quality any more than you can fake a good meal. William S. Burroughs _______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
I am using the standard PD installed from apt-get on Ubuntu Dapper, the external is compiled in debug mode. build trace was...
make -f ../../flext/buildsys/gnumake-sub.mak PLATFORM=lnx RTSYS=pd COMPILER=gcc BUILDPATH=../../flext/buildsys/ PKGINFO=package.txt BUILDCLASS=ext USRCONFIG=config.txt USRMAKE=../build/gnumake-lnx-gcc.inc TARGETMODE=debug TARGETTYPE=single DEBUG=1 _build_ make[1]: Entering directory `/home/ronoc/audio_development/dynamic_comb/src' mkdir -p pd-linux/debug-single g++ -c -msse -mfpmath=sse -ffast-math -D_DEBUG -pthread -fPIC -g -DFLEXT_SYS=2 -I/usr/lib/pd/src -I/usr/local/include/flext ResonComb.cpp -o pd-linux/debug-single/ResonComb.opp g++ -c -msse -mfpmath=sse -ffast-math -D_DEBUG -pthread -fPIC -g -DFLEXT_SYS=2 -I/usr/lib/pd/src -I/usr/local/include/flext DynamicComb.cpp -o pd-linux/debug-single/DynamicComb.opp g++ -pthread -shared -g -L/usr/lib/pd/bin -L/usr/local/lib -o pd-linux/debug-single/resoncomb~.pd_linux pd-linux/debug-single/ResonComb.opp pd-linux/debug-single/DynamicComb.opp -lsndobj -lflext-pd_sd chmod 755 pd-linux/debug-single/resoncomb~.pd_linux make[1]: Leaving directory `/home/ronoc/audio_development/dynamic_comb/src'
The funny thing was it managed to set the breakpoint properly the first time.
thanks for your attention.
C On Mon, 2006-11-13 at 11:12 -0500, james tittle wrote:
On Nov 13, 2006, at 9:59 AM, forwinder wrote:
Still can't get the bugger to set a break point though. GDB was helpfully in that once PD died I could at least the back trace.
...did you compile pd with "-g -O0"? Are you stripping symbols somewhere? What platform are you trying to debug on?
james
-
chris clepper -
Conor J Curran -
forwinder
-
Hans-Christoph Steiner -
james tittle -
Mathieu Bouchard -
Miller Puckette -
Tim Blechmann