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
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
