Summary: | Dynamic library debugging on MacOS X 10.12 (Sierra) and dyld 15 is broken | ||
---|---|---|---|
Product: | gdb | Reporter: | Stefan Budeanu <stefan.mb> |
Component: | gdb | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | benconvey, chrisfriedt, evan.torrie, jothiram.s, mephi42, pedro, question123446, rostyslav.skrypnyk, shahzeb001, simon, stefan.mb, tromey, wsimmons |
Priority: | P2 | ||
Version: | HEAD | ||
Target Milestone: | 8.3 | ||
Host: | Target: | *-*-darwin* | |
Build: | Last reconfirmed: |
Description
Stefan Budeanu
2016-12-18 05:23:56 UTC
It turns out the fork crashing issues may be due to the children having software breakpoints left over after fork. I get a similar problem with lldb, and disassembling the core dump shows `INT 3` instructions being inserted in gdb_image_notifier. I think that is a separate problem (though also annoying). The hack I linked to got gdb starting but I've run into a new problem setting breakpoints in my library because the location of my functions seem to also be read as offsets instead of the relocated addresses. This issue only seems to happen for certain object files and the raw offsets are being read directly from the DWARF2 info as far as I can tell. In my case, the gdb is starting the original program successfully, but gdb) info shared does not show any information. Also, the break points that I had set in the shared library are not detected and the execution does not stop there. Any update on this? I've uninstalled and then installed gdb twice (via brew). I've also codesigned it. Still get "No shared libraries loaded at this time.". Really frustrating. macOS: 10.12.4 I'm also encountering this on 10.12.6 ... sigh.. This also occurs on Mac OS X 10.13 (High Sierra) This problem still isn't resolved, but I came up with a solution: Simply run a docker container I've built which has GDB within it. Instructions on my github: https://github.com/shahzeb1/cpp-gdb-docker-image Gdb 8.0.1 doesn't have this problem as I see. However, the dynamic library still can't debug at all. It can't collect debug symbols... #sadface :( The simple hard fact is that unfortunately the macOS/Darwin port isn't really getting much attention. Most gdb devs tend to run/focus on GNU/Linux. We need someone motivated to actually dig in to the sources, study the issue in detail, and fix the issue. Who knows, maybe end up becoming port maintainer. :-) This could be you! same issue on high sierra ( 10.13.2 ) :( These days, things are also just being run as Linux binaries inside of a Docker container on Mac OS X.. except those rare occasions when it *really* needs to be MachO. Maybe one of these days I'll get around to it. The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=79b32f4a3a109321cb9a99014293b0ade57535ab commit 79b32f4a3a109321cb9a99014293b0ade57535ab Author: Xavier Roirand <roirand@adacore.com> Date: Wed Aug 22 12:11:14 2018 +0200 Darwin: Handle unrelocated dyld. On Darwin, debugging an helloworld program with GDB does not work and ends with: (gdb) set startup-with-shell off (gdb) start Temporary breakpoint 1 at 0x100000fb4: file /tmp/helloworld.c, line 1. Starting program: /private/tmp/helloworld [New Thread 0x2703 of process 18906] [New Thread 0x2603 of process 18906] [1]+ Stopped ./gdb/gdb /tmp/helloworld When debugging with lldb, instead of having the STOP signal, we can see that a breakpoint is not set to a proper location: Warning: Cannot insert breakpoint -1. Cannot access memory at address 0xf726 Command aborted. The inserted breakpoint is the one used when GDB has to stop the target when a shared library is loaded or unloaded. The notifier address used for adding the breakpoint is wrong thus the above failure. This notifier address is an offset relative to dyld base address, so the value calculation has to be updated to reflect this. This was tested on High Sierra by trying to run a simple "hello world" program. gdb/ChangeLog: PR gdb/20981: * solib-darwin.c (darwin_get_dyld_bfd): New function. (darwin_solib_get_all_image_info_addr_at_init): Update call. (darwin_handle_solib_event): New function. (darwin_solib_create_inferior_hook): Handle unrelocated dyld. Change-Id: I7dde5008c9158f17b78dc89bd7f4bd8a12d4a6e1 I've pushed a variant of Xavier's patch which fixes the problem for me on High Sierra. I think this is fixed. However, I could only test High Sierra. So, if you can check out git master gdb and try it on other versions, that would be nice. I am going to close this bug; but feel free to report back here (I'll still be listening) and/or reopen if there are similar problems. I also encounter "warning: unhandled dyld version (16)" (now the version has incremented) on Mac OS Catalina 10.15.4. Also, every other time I experience the issue of hanging described here: https://sourceware.org/bugzilla/show_bug.cgi?id=24069 I tried both installing via Homebrew and building from source. |