Thanks for these I was unclear - I’m trying to debug an external (all flags ok) to a downloaded version of Pd and this is where the sandboxing is freaking out lldb. In the article I pointed, they show how to modify the entitlements of the host, which I did successfully for a downloaded version of SuperCollider, but I don’t seem able to do this with the downloaded version of Pd...
> On 28 Feb 2023, at 11:51, Dan Wilcox <[email protected]> wrote: > > Ah again... if you are debugging an external, it should also be compiled with > optimization disabled and debugging symbols enabled, typically CFLAGS="-O0 -g" > >> On Feb 28, 2023, at 12:43 PM, Dan Wilcox <[email protected] >> <mailto:[email protected]>> wrote: >> >> Ah, I forgot an important point: first configure with debugging symbols. >> >> ./configure --enable-debug >> >> If building from a git clone, first generate configure using autoconf via: >> >> ./autogen.sh >> >> Actually, this info is in the INSTALL.txt file, but I'm writing it here >> anyway. ;) >> >>> On Feb 28, 2023, at 12:39 PM, Dan Wilcox <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>>> On Feb 28, 2023, at 12:00 PM, [email protected] >>>> <mailto:[email protected]> wrote: >>>> >>>> Hello >>>> >>>> So we all know how Apple is sandboxing like hell. >>> >>> Sure, but allowing *any* old program to be debugged / decompiled in >>> realtime is not the best for security implications, at least Apple thinks >>> so. >>> >>> Your subject is a little misleading as the "Xcode debugger" is essential >>> lldb. Xcode itself simply wraps lldb when debugging and provides a UI top >>> interact with it. In fact, on a debug build crash in Xcode, you can enter >>> lldb commands directly into the console, ie. "bt" will provide a backtrace >>> directly. >>> >>>> How do people attach a debugger to pd to do development? >>> >>> "lldb" like "gdb" >>> >>> For quick tests of a known crasher, I usually use: >>> >>> make >>> cd bin >>> lldb pd >>> >>> This will use the system Tcl/Tk which has had issues for years now, but is >>> enough for quick testing. >>> >>> For best testing, build the .app and invoke the pd binary inside it. For >>> example: >>> >>> make >>> make app >>> lldb Pd-0.53-2.app/Contents/Resources/bin/pd >>> >>> Once lldb launches, you have to start the process: >>> >>> process launch >>> >>> When a crash happens, you can get the backtrace with "bt", change frames >>> with "f #", and print variables via "v". If you have used gdb before, this >>> is a helpful crib sheet: >>> >>> https://lldb.llvm.org/use/map.html <https://lldb.llvm.org/use/map.html> >>> >>> Note: If you are using a newer macOS system and want to *also* use a newer >>> version of Tcl/Tk, build Wish.app first then use it to make the Pd .app >>> bundle: >>> >>> ./macos/tcltk-wish.sh 8.6.12 >>> >>> produces a Wish-8.6.12.app. Next use it to build Pd .app with: >>> >>> ./mac/osx-app.sh -w Wish-8.6.12.app 0.53-2 >>> >>> Now you can change the C sources and rebuild with: >>> >>> make >>> ./mac/osx-app.sh -w Wish-8.6.12.app 0.53-2 >>> >>>> Do I have to recompile pd myself as the long winded detour? >>> >>> If you want debugging symbols, yes. Fortunately it is relative easy to >>> compile Pd so I don't consider it "long-winded." In fact, we have spent >>> quite a bit of time to make this both possible *and* relatively easy. (See >>> above.) >>> >>> -------- >>> Dan Wilcox >>> @danomatika <http://twitter.com/danomatika> >>> danomatika.com <http://danomatika.com/> >>> robotcowboy.com <http://robotcowboy.com/> >>> >>> >>> >> >> -------- >> Dan Wilcox >> @danomatika <http://twitter.com/danomatika> >> danomatika.com <http://danomatika.com/> >> robotcowboy.com <http://robotcowboy.com/> >> >> >> > > -------- > Dan Wilcox > @danomatika <http://twitter.com/danomatika> > danomatika.com <http://danomatika.com/> > robotcowboy.com <http://robotcowboy.com/> > > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
