Is there a way to get debugging symbols for CGO code linked into Go?

I have some Cgo code that I'm linking into my Go binary. I've got Cgo running and building my code and wrapper. After some recent changes, I started getting a double-free in my C++ that I'm linking in. I've tried running my binary under lldb and it does trap the malloc panic, but the symbols are not especially useful.

In vanilla C or C++ I've used -g3 to get rich debugging symbols that includes variable names and source. This makes using lldb much more productive. However, I'm having some issues getting these symbols to show up in my go binary. I've noticed that in the backtrace my function appears as main'foo, where foo is the name of my function. There is no other debug info present though, all I get is a trace of assembly and memory pointers/registers.

I've tried invoking go build with CGO_CFLAGS="-g3" CGO_CXXFLAGS="-g3" but the binary still doesn't have the symbols. I've also tried adding -g3 to the CFLAGS/CXXFLAGS in my .go file where I set other flags (before import "C") but this doesn't seem to work either. I can't think of any other way to get this debugging info added into my binary - is there some Go-specific flag or build sequence that enables this?

I don't know how the process of go & C++ linking works. But a brief description of how debug information is handled on OS X might help you figure out where the debug information is being lost.

On OS X as on most systems, the debug information for an individual source file compile goes into the .o file made from it. You can verify that your .o file got debug information in a variety of ways, here's one:

 lldb -o "image dump sections" Target.o --batch | grep DWARF
  0x00000300 container        [0x0000000000061538-0x0000000000782c77)  rwx  0x00061cb8 0x0072173f 0x00000000 Target.o.__DWARF
  0x00000009 dwarf-str        [0x0000000000061538-0x00000000004eeabc)  rwx  0x00061cb8 0x0048d584 0x02000000 Target.o.__DWARF.__debug_str
  0x0000000a dwarf-loc        [0x00000000004eeabc-0x00000000004ef493)  rwx  0x004ef23c 0x000009d7 0x02000000 Target.o.__DWARF.__debug_loc
  0x0000000b dwarf-abbrev     [0x00000000004ef493-0x00000000004f09a7)  rwx  0x004efc13 0x00001514 0x02000000 Target.o.__DWARF.__debug_abbrev
  0x0000000c dwarf-info       [0x00000000004f09a7-0x00000000006ea7f1)  rwx  0x004f1127 0x001f9e4a 0x02000000 Target.o.__DWARF.__debug_info
  0x0000000d dwarf-ranges     [0x00000000006ea7f1-0x00000000006ec481)  rwx  0x006eaf71 0x00001c90 0x02000000 Target.o.__DWARF.__debug_ranges
  0x0000000e dwarf-macinfo    [0x00000000006ec481-0x00000000006ec482)  rwx  0x006ecc01 0x00000001 0x02000000 Target.o.__DWARF.__debug_macinfo
  0x0000000f apple-names      [0x00000000006ec482-0x000000000071134e)  rwx  0x006ecc02 0x00024ecc 0x02000000 Target.o.__DWARF.__apple_names
  0x00000010 apple-objc       [0x000000000071134e-0x0000000000711372)  rwx  0x00711ace 0x00000024 0x02000000 Target.o.__DWARF.__apple_objc
  0x00000011 apple-namespaces [0x0000000000711372-0x00000000007116d6)  rwx  0x00711af2 0x00000364 0x02000000 Target.o.__DWARF.__apple_namespac
  0x00000012 apple-types      [0x00000000007116d6-0x0000000000748797)  rwx  0x00711e56 0x000370c1 0x02000000 Target.o.__DWARF.__apple_types
  0x00000015 dwarf-line       [0x000000000075d348-0x0000000000782c77)  rwx  0x0075dac8 0x0002592f 0x02000000 Target.o.__DWARF.__debug_line

If you don't see anything here, then the compiler isn't emitting debug information...

The next step is specific to Darwin, instead of putting the debug information into the output of the link stage, the debug info is left in the .o files, and a "debug map" is inserted into the output image. That's how the debugger finds its way back to the .o files. You can see that by doing:

$ nm -ap <YourBinary> | grep OSO

you should see a list of all your .o files here. If you don't then at some point in the build process your binary is getting stripped (using at least strip -S) You have to find out when that is happening and not do that. Also check that the .o files are still where the entries you see from the command above say they are. It may be some part of the build process is moving them around, and the debugger can't find them anymore.