I have LLDB on my laptop and it passes.

$ go test -v -run=Lldb runtime
=== RUN   TestLldbPython
--- PASS: TestLldbPython (6.96s)
PASS
ok  	runtime	7.014s

My LLDB is older though.

$ lldb --version
lldb-1000.11.37.1
  Swift-4.2

Fails quite nicely for me, with the matching lldb version.
Just trying to use lldb by hand, it fails horribly with some sort of Python nonsense.
Using delve, the generated binary seems fine.

I assume this has something to do with updates to macOS.
Does anyone actually use lldb with Go?
It's never been anything other than incredibly frustrating for me.

Don't try this with MacPorts Python:

python
Python 2.7.16 (default, Mar  9 2019, 03:43:10) 
[GCC 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path.append("/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python")
>>> import lldb
Fatal Python error: PyThreadState_Get: no current thread
Abort trap: 6

Does anyone actually use lldb with Go?

I do, because of frustrations with gdb and codesigning. But I may be the only one.

Gdb worked for me last week, but not this week. Seriously.
I even code-signed it just now, but for some reason that didn't work.
Presumably security was enhanced in some way when I upgraded to Mojave.

But I may be the only one.

I sometimes do as well. But my use case doesn't really involve the python part (or even nicely formatted variables, etc.).

dwarfdump -verify is very whiny.
But it's whiny back to at least go-1.11.5
I don't know if this is the problem or not.

@andybons I’ve changed the milestone to 1.13, if for no other reason than it causes all.bash to fail. If we want to punt indefinitely, we should add a t.Skip to the test. I’ll defer to @dr2chase as to whether we want to fix soon or skip soon.

@josharian sounds good to me. No objection on my end.

It's not good that it causes all.bash to fail for Mojave users.
"Fix soon" assumes that "soon" is an actual option for "fix".

Change https://golang.org/cl/170281 mentions this issue: runtime: skip broken TestLldbPython

This may be related to whatever is going on in #29244, which causes a somewhat different failure on some Linux machines with the right (or wrong) combination of lldb and kernel versions.

It looks, though not quite proven, like this is a newish enhancement to a bug in lldb. The accompanying dwarf dumping tools fail to properly recognize "base address selection entries" (DWARF 4, section 2.6.2, page 30) and instead decodes them as beginning and ending address offsets, in turn mis-interpreting the actual beginning and ending offsets that follow.

Apparently lldb has historically failed to properly process base address selection entries and we hacked around it for Darwin, but now their mere presence causes failure. The string "base address ent" appears nowhere in the lldb sources.

It's reading the section start to finish rather than actually using the references? Great.

Unfortunately a base address selector is shorter than a location list entry -- it doesn't have a location expression length -- so a simple strategy of just zeroing them out won't work.

When I wrote this, I was uncomfortable actually changing the size of the .debug_loc section for fear of breaking subsequent link steps. We do have some precedent for that now, though, since DWARF compression does it. So it might be possible to actually strip the base address entries rather than leaving them around as junk data.

Change https://golang.org/cl/170638 mentions this issue: cmd/link: revert CL 98075 because LLDB is very picky now

@heschik we're already changing DWARF section sizes in the object file reader, e.g. patchDWARFName.

That's changing the size of symbols on their way in to the linker, which should be pretty harmless. I'm pretty sure that removeDwarfAddrListBaseAddress used to run after sections had been laid out and relocations had been processed, so changing symbol sizes would have changed section sizes and layouts. But if that was ever true, it's not now, because https://golang.org/cl/111237 moved all this work before section layout is done. So it should be totally fine to just remove the base address entries entirely.

To be clear, I am benchmarking a CL that removes the base address entries entirely, and though that made dwarfdump happy (and gnu objdump and delve remained happy), it did not fix the lldb test failure.

Change https://golang.org/cl/170798 mentions this issue: [release-branch.go1.12] runtime: skip broken TestLldbPython

On Mojave, it looks like your option for debugging Go is Delve, even with the Go binaries fixed to make dwarfdump happy. The binaries on Macos were in fact technically incorrect because there were no references to the BAS entries in .debug_loc. Objdump (from macports, gobjdump) would diagnose this problem correctly, dwarfdump would get completely confused.

Gdb from homebrew or from macports does not work, even with updated codesigning, even with with a properly configured .gdbinit (must contain set startup-with-shell off), even with proper python support (port install gdb +python27).

Also, just to be clear, I'm going to work on other problems. I cannot see recommending anything but Delve to Go users on Macos, because so far attempting to use the other debuggers merely wastes time.

Change https://golang.org/cl/171158 mentions this issue: cmd/link: replace Base Address Selection Entry w/ new relocation

By-the-way, this is looking more like someone enhanced the bejeezus out of the LLVM Dwarf library concurrent with the Mojave-related XCode upgrade ; all sorts of stuff is broken, and it's not the Go side that's broken. This hasn't been proven in this case yet, but given how the last few weeks have been spent it looks like a good bet.

Just for example, if you want to debug with lldb, you'll need to turn off compressed dwarf, because the splitdwarf trick no longer works.