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;
}
}
Comment #1 by ibuclaw — 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
Comment #2 by jack — 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."
Comment #3 by ibuclaw — 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.
Comment #4 by code — 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.
Comment #5 by robert.schadek — 2024-12-13T18:44:14Z