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/".
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
33      {
(gdb) print(x)
$1 = (t_tabdump *) 0x555555971ef0


_______________________________________________ mailing list
UNSUBSCRIBE and account-management ->

_______________________________________________ mailing list
UNSUBSCRIBE and account-management ->

Reply via email to