After starting gdb --args etc. as in your example, and after calling run I get this:
[Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Detaching after fork from child process 3889. [New Thread 0x7ffff61ff700 (LWP 3891)]
(Pd is on PID 3888 in this case)
and there is no gdb prompt. If I put a break point in before I hit 'run' I get the same, and the process doesn't break, even though the function I wanted to break is surely called.
On 04/12/2018 12:19 PM, IOhannes m zmölnig wrote:
On 04/12/2018 11:18 AM, David Medine wrote:
@Miller, no I hadn't. Thanks! I knew there was something like that I had neglected. Now I am able to debug with gdb.
@iohannes, I am still having trouble with this technique. If I run Pd from the gdb prompt (with -nrt and -stderr) and a break point within the extern (meaning object not compiled into pd) nothing happens when I run the function where I want to break.
but the breakpoint gets resolved correctly? e.g. after a warm-up run, setting the breakpoint yields an address:
$ gdb --args pd -nrt -stderr -lib zexy ./reference/tabdump-help.pd [...] (gdb) run [...] (gdb) break tabdump_bang Breakpoint 1 at 0x7ffff5cb6730: file tabdump.c, line 33. (gdb) run [ ...send "bang" to tabdump... ] Thread 1 "pd" hit Breakpoint 1, tabdump_bang (x=0x555555971ef0) at tabdump.c:33 33 { (gdb) print(x) $1 = (t_tabdump *) 0x555555971ef0 (gdb)
gfdsmrt IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list