How to set debug point

[wsdwsd0829]

When I run debug-objc binary e.g. id obj = [[NSObject alloc] init];

the debug point +alloc is not triggering in NSObject.mm
Mac version:10.14.6 Xcode: Version 11.3.1

Do you know why and how I can fix it? Thanks.

[RetVal]

add the breakpoint to function objc_alloc ? have a try.

[wsdwsd0829]

I tried that and not working. The only change i made is to change signing's Team and use "Automatically manage signing" and change target of debug-objc's min target version to 10.14 to match mine.

What's your tested os & xcode version? Maybe I need to update xcode and os?

[wsdwsd0829]

Unfortunately updating to Catalina did not fix it either.

[RetVal]

OSX 10.15.3, Xcode 11.4
I think maybe you can running the demo project, and set a breakpoint to pause the process, type 'image list' to the console and check the path of the runtime.

[wsdwsd0829]

This is the output:
(lldb) image list
[ 0] F2AC94E8-A1C2-30F5-8727-84D92AD89951 0x0000000100000000 /Users/maxwang/Library/Developer/Xcode/DerivedData/objc-dnbfetcywolbragldaprohldvehz/Build/Products/Debug/debug-objc
[ 1] 1F893B81-89A5-3502-8510-95B97B9F730D 0x0000000100009000 /usr/lib/dyld
[ 2] 20AC082F-2DB7-3974-A2D4-8C5E01787584 0x00007fff6e517000 /usr/lib/libobjc.A.dylib
[ 3] 9A74FA97-7F7B-3929-B381-D9514B1E4754 0x00007fff37dbc000 /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
[ 4] DB8310F1-272D-3533-A840-3B390AF55C26 0x00007fff6c6b7000 /usr/lib/libSystem.B.dylib
[ 5] 9E632A1E-9622-33D6-BCCE-23AC16DAA6B7 0x00007fff35706000 /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
[ 6] 1C880020-396D-3F91-BE27-5A09A9239F68 0x00007fff6c9f0000 /usr/lib/libc++abi.dylib
[ 7] 08199809-33CA-321E-9B9D-FD5B2BC64580 0x00007fff6c99d000 /usr/lib/libc++.1.dylib
[ 8] 5F90FFCE-403B-3724-991D-BA32401D99C5 0x00007fff6f4b3000 /usr/lib/system/libcache.dylib
[ 9] C7A5E3F7-1E5A-3785-875A-B6647082B614 0x00007fff6f4b9000 /usr/lib/system/libcommonCrypto.dylib
[ 10] A517E149-2D25-3C04-BCEF-F69149C85B18 0x00007fff6f4c5000 /usr/lib/system/libcompiler_rt.dylib

[RetVal]

the path of the runtime told that your app loaded the system version of the binary, so the breakpoint didn't make sense, check the snapshot of my screen, you can see the demo loaded the binary which was compiled from the project.

maybe you can check the build location of the runtime and your demo app, make sure the location of these two was same.

[lanza]

How are you doing this? The debug-objc binary has LC 13: LC_LOAD_DYLIB /usr/lib/libobjc.A.dylib. Are you manually install_name_tooling this to a relative path? I had to use DYLD_INSERT_LIBRARIES=path/to/built/libobjc.A.dylib. Not even sure why that worked given the load command is for the absolute path libobjc.A.dylib.

[wsdwsd0829]

I could not find install_name_tool or DYLD_INSERT_LIBRARIES in Build Setting of debug-objc or objc target.
I did not change any settings after git clone. Shouldn't it be setting the build use the debug build of runtime when I just clone the project (I just cloned without changing anything, except cert/signing)?
What setting do you suggest I can check and try to change. I am not really familiar with which path is related to point to the right objc dylib.

[lanza]

I don’t know how to use Xcode.

I just did
‘’’
DYLD_INSERT_LIBRARIES=path/to/libobjc.A.dylib lldb path/to/debug-objc
‘’’

[RetVal]

I don’t know how to use Xcode.

I just did
‘’’
DYLD_INSERT_LIBRARIES=path/to/libobjc.A.dylib lldb path/to/debug-objc
‘’’

maybe you can check the build location of the runtime and your demo app, make sure the location of these two was same.

[wsdwsd0829]

They are the same both pointing to "build" path. [image: image.png] [image: image.png]

…

On Wed, Apr 1, 2020 at 5:05 AM RetVal ***@***.***> wrote: I don’t know how to use Xcode. I just did ‘’’ DYLD_INSERT_LIBRARIES=path/to/libobjc.A.dylib lldb path/to/debug-objc ‘’’ maybe you can check the build location of the runtime and your demo app, make sure the location of these two was same. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABIWVZEYWZGYZ7JKVRUBJSDRKMUXVANCNFSM4LSEBUYA> .

[programingHaozi]

They are the same both pointing to "build" path. [image: image.png] [image: image.png]
…
On Wed, Apr 1, 2020 at 5:05 AM RetVal @.***> wrote: I don’t know how to use Xcode. I just did ‘’’ DYLD_INSERT_LIBRARIES=path/to/libobjc.A.dylib lldb path/to/debug-objc ‘’’ maybe you can check the build location of the runtime and your demo app, make sure the location of these two was same. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIWVZEYWZGYZ7JKVRUBJSDRKMUXVANCNFSM4LSEBUYA .

I have the same problem, try everything i can do but none of them worked, so I give up the newest version，and try compile 756.2 which Git commit is 20d965f，and it worked！hope it can help

[lanza]

ld64 links against the dylibs install path. For the built libobjc.A.dylib this is /usr/lib/libobjc.A.dylib as set by the Installation Directory value of /usr/lib in Xcode. So ld64 will put that as the LD_LOAD_DYLIB for anything you link against the built library. However, Xcode also injects -frameword Foundation into the main.o objectfile as an LC_LINKER_OPTION which implicitly imports /usr/lib/libobjc.A.dylib. So the workaround for this whole thing seems ridiculous. I'd just stick to DYLD_INSERT_LIBRARIES=build/Debug/libobjc.A.dylib lldb debug-objc.

[wsdwsd0829]

ba21fe7 this commit worked for me on Mojave and Catalina. (756.2 20d965f did not).

Thanks @programingHaozi for the idea to try other commits.

[RetVal]

Maybe you can check the SIP status of your machine, typing csrutil status in your terminal, please make sure the status was disabled. I tested this using an empty machine and couldn't load the custom version of the runtime when the SIP was enabled, hope it make sense.