www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.debugger - macOS: debugging hell - strange behavior in lldb and gdb

reply Relja Ljubobratovic <ljubobratovic.relja gmail.com> writes:
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
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
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
parent reply Relja Ljubobratovic <ljubobratovic.relja gmail.com> writes:
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:
 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.
That did it! With -gc lldb works properly. Thank you John! Any reason this flag is not included on dub --build=debug --compiler=ldc2?
Feb 14
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
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:
 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.
That did it! With -gc lldb works properly. Thank you John! Any reason this flag is not included on dub --build=debug --compiler=ldc2?
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?
Feb 14
parent reply Relja Ljubobratovic <ljubobratovic.relja gmail.com> writes:
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
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
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:
 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.
-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"] } }
 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
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..
Feb 14
next sibling parent Relja Ljubobratovic <ljubobratovic.relja gmail.com> writes:
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:
 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.
-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.
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).
 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
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
next sibling parent reply Relja Ljubobratovic <ljubobratovic.relja gmail.com> writes:
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
parent reply Jacob Carlborg <doob me.com> writes:
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
parent Relja Ljubobratovic <ljubobratovic.relja gmail.com> writes:
On Wednesday, 15 February 2017 at 12:44:59 UTC, Jacob Carlborg 
wrote:
 Sort answer: LLDB/LLVM.
Alright, thanks!
Feb 15
prev sibling parent John Colvin <john.loughran.colvin gmail.com> writes:
On Wednesday, 15 February 2017 at 07:45:41 UTC, Jacob Carlborg 
wrote:
 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.
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.
Feb 15