digitalmars.D.debugger - macOS: debugging hell - strange behavior in lldb and gdb
- Relja Ljubobratovic (37/37) Feb 12 2017 Hey guys,
- John Colvin (6/9) Feb 14 2017 You might find adding symbolic debug info will be useful, which
- Relja Ljubobratovic (4/13) Feb 14 2017 That did it! With -gc lldb works properly. Thank you John!
- John Colvin (4/18) Feb 14 2017 The docs say it is, but they could be wrong. Could you run dub
- Relja Ljubobratovic (20/23) Feb 14 2017 Sure, here's what I'd think is the relevant part:
- John Colvin (21/44) Feb 14 2017 -g is there though, which is actually what the docs say.
- Relja Ljubobratovic (9/35) Feb 14 2017 Well, while I was on Ubuntu, I was using gdb (through cgdb) with
- Jacob Carlborg (5/9) Feb 14 2017 D should support LLDB, or LLDB should support D (whichever way it is).
- Relja Ljubobratovic (5/7) Feb 15 2017 Any hints on this behavior with lldb on my system, without -gc
- Jacob Carlborg (7/10) Feb 15 2017 Sort answer: LLDB/LLVM. Longer answer:
- Relja Ljubobratovic (3/4) Feb 15 2017 Alright, thanks!
- John Colvin (5/15) Feb 15 2017 Judging by what was done with gdb by Iain, it's lldb that will
Hey guys,
I've had zero luck with debuggers on macOS. Here's the story:
lldb - thread step-over (n) works as thread step-in (s).
Everything else seems to be working fine. I could work with
step-in followed by step-out (which in combination works as
step-over).
I don't have this issue with C/C++ programs.
I'm compiling with ldc (with dub --build=debug).
ldc2 --version:
====
LDC - the LLVM D compiler (1.1.0-beta4):
based on DMD v2.071.2 and LLVM 3.9.0
built with LDC - the LLVM D compiler (1.1.0-beta4)
Default target: x86_64-apple-darwin16.4.0
Host CPU: skylake-avx512
http://dlang.org - http://wiki.dlang.org/LDC
Registered Targets:
x86 - 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
====
lldb --version:
====
lldb-360.1.70
====
Behavior is the same with dmd v2.072.0.
With gdb I'm having the reverse story - `s` works as `n`, i.e. I
cannot step into a function. Again, workaround is to set a
breakpoint inside the function, and continue the program. But
that's maybe even more frustrating since symbol names are not
demangled and I have to define a line in the source. Also gdb
works fine with C/C++.
gdb --version:
====
GNU gdb (GDB) 7.12
====
Has anyone had similar problems? I've searched the web for
similar issues, but couldn't find the solution.
Feb 12 2017
On Sunday, 12 February 2017 at 10:27:38 UTC, Relja Ljubobratovic wrote:Hey guys, I've had zero luck with debuggers on macOS. Here's the story: [...]You might find adding symbolic debug info will be useful, which is done with -g or -gc. You might also want to experiment with the --debuglib settings and/or --link-debuglib for dealing with phobos.
Feb 14 2017
On Tuesday, 14 February 2017 at 15:37:34 UTC, John Colvin wrote:On Sunday, 12 February 2017 at 10:27:38 UTC, Relja Ljubobratovic wrote:That did it! With -gc lldb works properly. Thank you John! Any reason this flag is not included on dub --build=debug --compiler=ldc2?Hey guys, I've had zero luck with debuggers on macOS. Here's the story: [...]You might find adding symbolic debug info will be useful, which is done with -g or -gc.
Feb 14 2017
On Tuesday, 14 February 2017 at 18:08:18 UTC, Relja Ljubobratovic wrote:On Tuesday, 14 February 2017 at 15:37:34 UTC, John Colvin wrote:The docs say it is, but they could be wrong. Could you run dub with -v (and without any manually added -gc) and share the output?On Sunday, 12 February 2017 at 10:27:38 UTC, Relja Ljubobratovic wrote:That did it! With -gc lldb works properly. Thank you John! Any reason this flag is not included on dub --build=debug --compiler=ldc2?Hey guys, I've had zero luck with debuggers on macOS. Here's the story: [...]You might find adding symbolic debug info will be useful, which is done with -g or -gc.
Feb 14 2017
On Tuesday, 14 February 2017 at 20:32:53 UTC, John Colvin wrote:The docs say it is, but they could be wrong. Could you run dub with -v (and without any manually added -gc) and share the output?Sure, here's what I'd think is the relevant part: Performing "debug" build using ldc2 for x86_64. File '/Users/relja/Projects/dlangplayground/dub.json' modified, need rebuild. dlangplayground ~master: building configuration "application"... ldc2 -mcpu=haswell -of.dub/build/application-debug-posix.osx-x86_64-ldc_2071-A59B2D18A3A7E59FF17DA8905B67 3B0/dlangplayground -d-debug -g -w -oq -od=.dub/obj -d-version=Have_dlangplayground -Isource/ source/app.d -vcolumns So, no -gc. Btw. it seems like I'm using dub v1.1.2 from homebrew: $ dub --version DUB version unknown, built on Jan 16 2017 $ readlink /usr/local/bin/dub ../Cellar/dub/1.1.2/bin/dub I'll test this with newer releases in the next few days, and if situation is the same, I'll file a bug. Once again, thanks man - feels fantastic having a debugger once again! :) Cheers, Relja
Feb 14 2017
On Tuesday, 14 February 2017 at 23:35:15 UTC, Relja Ljubobratovic wrote:On Tuesday, 14 February 2017 at 20:32:53 UTC, John Colvin wrote:-g is there though, which is actually what the docs say. gdb should suppport D (assuming it's not an ancient gdb), so -g should be better there. Overall, gdb is a better debugger for D. -g means D debug info, -gc means pretend to be C. The most portable way to get -gc in your debug builds, add this to the project's dub.sdl buildType "debug" { buildOptions "debugMode" "debugInfoC" } or if you're using dub.json: "buildTypes": { "debug": { "buildOptions": ["debugMode", "debugInfoC"] } }The docs say it is, but they could be wrong. Could you run dub with -v (and without any manually added -gc) and share the output?Sure, here's what I'd think is the relevant part: Performing "debug" build using ldc2 for x86_64. File '/Users/relja/Projects/dlangplayground/dub.json' modified, need rebuild. dlangplayground ~master: building configuration "application"... ldc2 -mcpu=haswell -of.dub/build/application-debug-posix.osx-x86_64-ldc_2071-A59B2D18A3A7E59FF17DA8905B67 3B0/dlangplayground -d-debug -g -w -oq -od=.dub/obj -d-version=Have_dlangplayground -Isource/ source/app.d -vcolumns So, no -gc.Btw. it seems like I'm using dub v1.1.2 from homebrew: $ dub --version DUB version unknown, built on Jan 16 2017 $ readlink /usr/local/bin/dub ../Cellar/dub/1.1.2/bin/dub I'll test this with newer releases in the next few days, and if situation is the same, I'll file a bug. Once again, thanks man - feels fantastic having a debugger once again! :) Cheers, ReljaI maintain the D packages in homebrew, so let me know if you have any problems. homebrew is up to date with the latest stable dub release, so a quick brew update && brew upgrade dub should get you up to date..
Feb 14 2017
Relja Ljubobratovic <ljubobratovic.relja gmail.com> On Tuesday, 14 February 2017 at 23:56:22 UTC, John Colvin wrote:On Tuesday, 14 February 2017 at 23:35:15 UTC, Relja Ljubobratovic wrote:Well, while I was on Ubuntu, I was using gdb (through cgdb) with everything in order, so I'd expect the same on macOS. gdb version on the Ubuntu could only be older, I suppose, so I'd say that is not the problem. Nevertheless, I feel like lldb with c-like debugging will do just fine. Although its a shame there's so much hustle around such an important development tool (hope I'm the special case and other people have better experience).On Tuesday, 14 February 2017 at 20:32:53 UTC, John Colvin wrote:-g is there though, which is actually what the docs say. gdb should suppport D (assuming it's not an ancient gdb), so -g should be better there. Overall, gdb is a better debugger for D. -g means D debug info, -gc means pretend to be C.The docs say it is, but they could be wrong. Could you run dub with -v (and without any manually added -gc) and share the output?Sure, here's what I'd think is the relevant part: Performing "debug" build using ldc2 for x86_64. File '/Users/relja/Projects/dlangplayground/dub.json' modified, need rebuild. dlangplayground ~master: building configuration "application"... ldc2 -mcpu=haswell -of.dub/build/application-debug-posix.osx-x86_64-ldc_2071-A59B2D18A3A7E59FF17DA8905B67 3B0/dlangplayground -d-debug -g -w -oq -od=.dub/obj -d-version=Have_dlangplayground -Isource/ source/app.d -vcolumns So, no -gc.I maintain the D packages in homebrew, so let me know if you have any problems. homebrew is up to date with the latest stable dub release, so a quick brew update && brew upgrade dub should get you up to date..Awesome, thanks for the good work!
Feb 14 2017
On 2017-02-15 00:56, John Colvin wrote:-g is there though, which is actually what the docs say. gdb should suppport D (assuming it's not an ancient gdb), so -g should be better there. Overall, gdb is a better debugger for D. -g means D debug info, -gc means pretend to be C.D should support LLDB, or LLDB should support D (whichever way it is). LLDB is the system debugger on macOS. -- /Jacob Carlborg
Feb 14 2017
On Wednesday, 15 February 2017 at 07:45:41 UTC, Jacob Carlborg wrote:D should support LLDB, or LLDB should support D (whichever way it is). LLDB is the system debugger on macOS.Any hints on this behavior with lldb on my system, without -gc flag? (step-over works as step-in). Also, forgot to ask - where would I knock for a fix? llvm or ldc repo?
Feb 15 2017
On 2017-02-15 09:36, Relja Ljubobratovic wrote:Any hints on this behavior with lldb on my system, without -gc flag? (step-over works as step-in). Also, forgot to ask - where would I knock for a fix? llvm or ldc repo?Sort answer: LLDB/LLVM. Longer answer: As John Colvin mentioned in the other post, for GDB there were changes required in both DMD and GDB, as far as I recall. But since the changes have already been done in DMD, I assume you only need to do changes in LLDB. -- /Jacob Carlborg
Feb 15 2017
On Wednesday, 15 February 2017 at 12:44:59 UTC, Jacob Carlborg wrote:Sort answer: LLDB/LLVM.Alright, thanks!
Feb 15 2017
On Wednesday, 15 February 2017 at 07:45:41 UTC, Jacob Carlborg wrote:On 2017-02-15 00:56, John Colvin wrote:Judging by what was done with gdb by Iain, it's lldb that will need modifying. In the meantime - while we wait for someone with the skills and time to do that - -gc will have to suffice.-g is there though, which is actually what the docs say. gdb should suppport D (assuming it's not an ancient gdb), so -g should be better there. Overall, gdb is a better debugger for D. -g means D debug info, -gc means pretend to be C.D should support LLDB, or LLDB should support D (whichever way it is). LLDB is the system debugger on macOS.
Feb 15 2017