Jump to page: 1 2
Thread overview
macOS: debugging hell - strange behavior in lldb and gdb
Feb 14, 2017
John Colvin
Feb 14, 2017
John Colvin
Feb 14, 2017
John Colvin
Feb 15, 2017
Jacob Carlborg
Feb 15, 2017
Jacob Carlborg
Feb 15, 2017
John Colvin
February 12, 2017
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.
February 14, 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.
February 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:
>> 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?

February 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:
>> 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?
February 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-A59B2D18A3A7E59FF17DA8905B6773B0/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
February 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:
>> 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-A59B2D18A3A7E59FF17DA8905B6773B0/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..
February 15, 2017
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-A59B2D18A3A7E59FF17DA8905B6773B0/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!
February 15, 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
February 15, 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?
February 15, 2017
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.
« First   ‹ Prev
1 2