GDB cannot be used to debug D programs on OS X

[dlangBugzillaToGithub]

Jack Stouffer (@JackStouffer) reported this on 2015-08-17T22:32:21Z

Transferred from https://issues.dlang.org/show_bug.cgi?id=14927

CC List

• David Nadlinger (@MartinNowak)
• Iain Buclaw (@ibuclaw)
• Luís Marques

Description

For reference:
    OSX 10.10.5
    GDB 7.9.1 (non apple; from homebrew)
    yes, GDB it is code signed
    Compiling with dmd -gc -gs

In GDB on OS X, trying to set a breakpoint in a file other than the one where the main function is, and stepping into functions in a file other than the one where the main function is, don't work. GDB will return something like:

    Cannot insert breakpoint 2.
    Cannot access memory at address 0x9bc06

when trying to insert a breakpoint in another file. GDB also treats the aforementioned step command as a continue because it can't read the file where the function is defined. Nothing changes when running the command as sudo either.

Two more pain points: `info locals` doesn't work. It responds with "No symbol table info available." And `info variables` returns the mangled D names for variables and not their real name, despite the language being set to D and doing `demangle [some_name]` returns the correct names.

Here is some sample code that does not work, e.g. you cannot step into the 'method' function:

a.d:
---------------------
import B;

void main() {
    auto b = Test();
    b.method();
}

b.d:
---------------------
module B;

struct Test {
    int b;

    void method() {
        b += 1;
    }
}

[dlangBugzillaToGithub]

ibuclaw (@ibuclaw) commented on 2015-08-18T10:20:10Z

> And `info variables` returns the mangled D names for variables and not their real name, despite the language being set to D and doing `demangle [some_name]` returns the correct names.

This is why you must *NEVER* use -gc on Linux/OSX/FreeBSD.  The -gc switch marks all functions as 'C' language functions, and gdb will not attempt to demangle such functions when it loads the symbol table.

FYI - there is a PR open that has been dwindling: https://github.com/D-Programming-Language/dmd/pull/4766

[dlangBugzillaToGithub]

jack (@JackStouffer) commented on 2015-08-18T13:15:25Z

(In reply to Iain Buclaw from comment #1)
> This is why you must *NEVER* use -gc on Linux/OSX/FreeBSD.  The -gc switch
> marks all functions as 'C' language functions, and gdb will not attempt to
> demangle such functions when it loads the symbol table.

Compiling with -g -gs doesn't fix any of the above problems. Doing `info locals` still responds with "No symbol table info available."

[dlangBugzillaToGithub]

ibuclaw (@ibuclaw) commented on 2015-08-18T15:04:15Z

(In reply to Jack Stouffer from comment #2)
> (In reply to Iain Buclaw from comment #1)
> > This is why you must *NEVER* use -gc on Linux/OSX/FreeBSD.  The -gc switch
> > marks all functions as 'C' language functions, and gdb will not attempt to
> > demangle such functions when it loads the symbol table.
> 

I wonder if DMD's choice of emitting symbols as _D3foo3bar instead of __D3foo3bar is biting them on OSX.

[dlangBugzillaToGithub]

code (@MartinNowak) commented on 2015-08-18T15:41:06Z

(In reply to Iain Buclaw from comment #3)
> (In reply to Jack Stouffer from comment #2)
> > (In reply to Iain Buclaw from comment #1)
> > > This is why you must *NEVER* use -gc on Linux/OSX/FreeBSD.  The -gc switch
> > > marks all functions as 'C' language functions, and gdb will not attempt to
> > > demangle such functions when it loads the symbol table.
> > 
> 
> I wonder if DMD's choice of emitting symbols as _D3foo3bar instead of
> __D3foo3bar is biting them on OSX.

It certainly is for the demangling side of things.