[SR-527] OS X: TestGo{UserExpression,Language,ASTContext} failing about llvm-project HOT 6 CLOSED

> FAIL: test_go_formatter_plugin (lang/go/formatters/TestGoFormatters.py)

This one is failing because SBFrame.FindVariable() is returning no type information on frame variables:

(lldb) b main.go:8
Breakpoint 2: where = a.out`main.main + 122 at main.go:8, address = 0x00000000000020ba
(lldb) run
Process 7348 launched: '/Users/tfiala/work/lldb-github/lldb/packages/Python/lldbsuite/test/lang/go/formatters/a.out' (x86_64)
Process 7348 stopped

• thread #1: tid = 0x161403, 0x00000000000020ba a.out`main.main + 122 at main.go:8, stop reason = breakpoint 2.1
  frame #0: 0x00000000000020ba a.out`main.main + 122 at main.go:8
  5 func main() {
  6 a := "my string"
  7 b := make([]int, 2, 7)
  -> 8 fmt.Println(a, b) // stop here
  9 }
  (lldb) po a
  "my string"

(lldb) po b
(len 2, cap 7)

(lldb) frame var
(<unimplemented>) a = "my string"
(<unimplemented>) b = (len 2, cap 7) {
[0] = 0
[1] = 0
}
(lldb)

Investigating that now.

from llvm-project.

I figured out what's going on with the first one. We've added a few more functions to TypeSystem without default implementations. It looks like we stubbed in some type name overrides for Swift purposes, and expect each TypeSystem-derived class to plug in an implementation.

I'm fixing this up to provide a reasonable default implementation that should work for both ClangASTContext and GoASTContext. Working on that now.

from llvm-project.

> FAIL: test_go_formatter_plugin (lang/go/formatters/TestGoFormatters.py)

The above test is fixed by:
```
commit f288c47457e9c62440a23924f18542290e3eafaf (HEAD -> master, origin/master, origin/HEAD)
Author: Todd Fiala <[email protected]>
Date: Tue Jan 12 10:30:19 2016
```

The remaining 3 tests still fail. Continuing to investigate those.

from llvm-project.

> FAIL: test_with_dsym_and_python_api_dsym (lang/go/expressions/TestExpressions.py)
> FAIL: test_with_dsym_and_python_api_dwarf (lang/go/expressions/TestExpressions.py)

Looking into these now.

I'm seeing some slightly unusual behavior w/r/t symbol lookups before getting too deep into this:

# Set breakpoint by line, since breakpoint by source regex and
# breakpoint by 'b main' doesn't work.  (Main shows up as main.main,
# not directly hittable by symbol name but is hittable by symbol regex).
(lldb) break set -f main.go -l 15
Breakpoint 2: where = a.out`main.myFunc + 191 at main.go:15, address = 0x00000000000020ff
(lldb) br list
Current breakpoints:
2: file = 'main.go', line = 15, exact_match = 0, locations = 1
  2.1: where = a.out`main.myFunc + 191 at main.go:15, address = a.out[0x00000000000020ff], unresolved, hit count = 0

(lldb) run
Process 42604 launched: '/Users/tfiala/work/lldb-github/lldb/packages/Python/lldbsuite/test/lang/go/expressions/a.out' (x86_64)
Process 42604 stopped
* thread #​1: tid = 0x51ed7, 0x00000000000020ff a.out`main.myFunc(i=interface {} @ 0x000000c820041f00) + 191 at main.go:15, stop reason = breakpoint 2.1
    frame #​0: 0x00000000000020ff a.out`main.myFunc(i=interface {} @ 0x000000c820041f00) + 191 at main.go:15
   12       a := [...]int{8, 9, 10}
   13       b := a[:]
   14       x := 22
-> 15       fmt.Println(a, b, x, i, myGlobal)  // Set breakpoint here.
   16   }
   17
   18   func main() {
(lldb) bt
* thread #​1: tid = 0x51ed7, 0x00000000000020ff a.out`main.myFunc(i=interface {} @ 0x000000c820041f00) + 191 at main.go:15, stop reason = breakpoint 2.1
  * frame #​0: 0x00000000000020ff a.out`main.myFunc(i=interface {} @ 0x000000c820041f00) + 191 at main.go:15
    frame #​1: 0x00000000000024d6 a.out`main.main + 134 at main.go:20
    frame #​2: 0x000000000002a340 a.out`runtime.main + 688 at proc.go:111
    frame #​3: 0x0000000000055ad1 a.out`runtime.goexit + 1 at asm_amd64.s:1721
(lldb) br set -n main
Breakpoint 3: where = a.out`main + 7 at rt0_darwin_amd64.s:49, address = 0x0000000000056a17
(lldb) br list
Current breakpoints:
2: file = 'main.go', line = 15, exact_match = 0, locations = 1, resolved = 1, hit count = 1
  2.1: where = a.out`main.myFunc + 191 at main.go:15, address = 0x00000000000020ff, resolved, hit count = 1

3: name = 'main', locations = 1, resolved = 1, hit count = 0
  3.1: where = a.out`main + 7 at rt0_darwin_amd64.s:49, address = 0x0000000000056a17, resolved, hit count = 0

# Note here how event though we list main.main in frame #​1 above, we don't
# resolve a breakpoint to it.
(lldb) br set -n main.main
Breakpoint 4: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) br list
Current breakpoints:
2: file = 'main.go', line = 15, exact_match = 0, locations = 1, resolved = 1, hit count = 1
  2.1: where = a.out`main.myFunc + 191 at main.go:15, address = 0x00000000000020ff, resolved, hit count = 1

3: name = 'main', locations = 1, resolved = 1, hit count = 0
  3.1: where = a.out`main + 7 at rt0_darwin_amd64.s:49, address = 0x0000000000056a17, resolved, hit count = 0

4: name = 'main.main', locations = 0 (pending)

# But, if we use a regex with main.main, we do resolve it.
(lldb) br set -r main.main
Breakpoint 5: where = a.out`main.main + 19 at main.go:19, address = 0x0000000000002463
(lldb)

This might be unrelated, but is curious nonetheless and seems to indicate some kind of symbolic lookup failure.

from llvm-project.

I've made a couple check-ins earlier to improve this situation.

First one:
apple/swift-lldb@4e87051

The commit message has details, but essentially the change above enabled function name symbol lookups based on user input to work (for example, when setting a breakpoint by symbol name) if either (1) the language of the 'set breakpoint' is set to "go", or (2) if the default settings for language is set to "go".

Second one:
apple/swift-lldb@af2c79d

This commit ensures that symbol name lookup for the base name portion of a Go method can be found. A number of code paths added for Swift assume that we will be able to find all occurrences (possibly too many, to be whittled down by later criteria) using the base name of an entity. So foo.bar.baz, we expect to be able to find by "baz" at least somewhere. This isn't the case with current Go debuginfo, as the DW_AT_name is set to the full module.funcname. The change manually adds accelerators for the base name of a DW_TAG_subprogram during dwarf indexing.

The change above allows 'break set -n main.main' and 'break set -n main' to find a function named 'main' in a package named 'main' without requiring the language to be set to "go". Essentially we're mapping Go's LLDB-internal symbol handling to match what we do for Swift.

We will later address this by allowing languages to alter some of the search logic, possibly causing a language-neutral (or language unaware) search criteria to be split into one per language type system, and then collapsing when several languages would result in the same kind of operation being performed. This issue I hit here highlighted the need for that.

I've got one more change in the works that does a similar fixup for type names that I did for function names. Once I'm done testing, I'll get that in as I think it will get all Go tests passing once again.

from llvm-project.

Fixed with merge:
apple/swift-lldb@4168b77

via final change:
apple/swift-lldb@becec19

from llvm-project.