Jump to page: 1 2
Thread overview
macOS: debugging hell - strange behavior in lldb and gdb
February 12
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
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
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
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
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
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
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
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
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
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