This is an archive of the discontinued LLVM Phabricator instance.

Switch to a different library-loaded notification function breakpoint in Darwin dyld
ClosedPublic

Authored by jasonmolenda on Dec 6 2022, 12:54 PM.

Details

Summary

Darwin's dynamic linker, dyld, calls a no-op function whenever libraries are loaded or removed from a process. There are two of these functions - one for older compatibility, which lldb is using, and actual one it calls first.

In a future patch, I'll change how lldb discovers the address of this function. lldb is currently not using the "canonical" one that I'll discover that way, and their arguments are slightly different, so this patch lays the groundwork by switching to this canonical notification function with the same discovery mechanism.

The important difference between these two is that the old function (lldb currently uses) is passed an array of uint64_t addresses of binary mach-o headers. In the new, canonical function, the headers are passed as an array of ptrsize -- so 32-bits, on a target like arm64_32 which is ILP32 (we don't have any genuine 32-bit targets that we still support). Beyond that, it's only a different function name.

Diff Detail

Event Timeline

jasonmolenda created this revision.Dec 6 2022, 12:54 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 6 2022, 12:54 PM
jasonmolenda requested review of this revision.Dec 6 2022, 12:54 PM

oops, slight misstatement from not reading the patch when I wrote the description. The function we currently use has an array of uint64_t's, the one I am switching to is given an array of dyld_image_info objects, the first element has the ptrsize address of the mach-o header.

jingham accepted this revision.Dec 8 2022, 4:19 PM

This makes sense. I think you should at least log if you can't read the memory dyld told you was where the image info should be. Seems like this is the sort of thing that shouldn't happen, but if it does we probably want to say something. Other than that minor grip, LGTM.

lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOS.cpp
329

Is it expected that this memory read fail? It seems weird to just not handle that case at all? Maybe at least log something here, otherwise it looks like we just get nothing w/o knowing why.

This revision is now accepted and ready to land.Dec 8 2022, 4:19 PM
JDevlieghere added inline comments.Dec 9 2022, 10:59 AM
lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOS.cpp
324–325

Nit: pretty sure GetAddressByteSize() returns an unsigned (uint32_t or uint8_t).

329

+1

Update patch to address Jim and Jonas' feedback, most importantly report a warning if we can't read one of the mach-o binary addresses that dyld is telling us are being added/removed.

After reverting to avoid CI bot failures on macos intel, this is an updated patch that (1) corrects the binary image count size, (2) allows for a fallback if it can't find the notification function lldb_image_notifier, by name.

Update the patch to address the failures we were hitting on the Intel macOS 10.15 CI bot. In addition to lldb_notifier_function, look for "gdb_notifier_function" which is what it was called back in macOS 10.15. Read the notification function address out of the dyld_all_image_infos as a last resort, if dyld_all_image_infos has been initialized.