On Wed, Jul 26, 2017 at 10:26 PM, Ian Lance Taylor <iant@golang.org> wrote:
> On Sat, Jul 22, 2017 at 11:08 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
>>> This patch to the gotools Makefile adds tests to `make check`.  We now
>>> test the runtime package using the newly built go tool, and test that
>>> cgo works by running the misc/cgo/test and misc/cgo/testcarchive
>>> tests.  Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
>>> Committed to mainline.
>>
>> There is now only one remaining gotools testsuite failure on alpha:
>>
>> FAIL: TestBreakpoint
>>         crash_test.go:106: testprog Breakpoint exit status: exit status 2
>>         crash_test.go:310: output:
>>                 SIGTRAP: trace trap
>>                 PC=2199039253124 m=0 sigcode=0
>>
>>                 goroutine 1 [running]:
>>
>>                 goroutine 3 [runnable]:
>>                 created by runtime.SetFinalizer
>>
>> /space/homedirs/uros/gcc-svn/trunk/libgo/go/runtime/mfinal.go:355
>> +1280
>>
>>
>>
>>                 want output containing: runtime.Breakpoint
>>
>> I would like to debug this one failure only. Is there a way to run
>> only one gotools test? Can you perhaps give a hint where to look in
>> the source?
>
> The test is TestBreakpoint in libgo/go/runtime/crash_test.go.  It is
> testing that if it runs a program that calls `runtime.Breakpoint`,
> then `runtime.Breakpoint` will appear in the stack trace that the
> program emits.
>
> It does this by building a test program.  The easy way to do this
> yourself is to run `make install` in your GCC build directory, set
> LD_LIBRARY_PATH if needed to include the newly installed libgo.so, and
> then do
>
> cd SRCDIR/libgo/go/runtime/testdata/testprog
> go build    # run the `go` program installed from gotools, building
> ./testprog; you can use `go build -o /tmp/x` if you like
> ./testprog Breakpoint
>
> On my x86_64 system that prints the appended, which includes the
> desired `runtime.Breakpoint` string.  On your system it fails to print
> a stack trace, but I don't know why.

The problem was following:

runtime.Breakpoint comprises only call to __builtin_trap (), which in
case of alpha maps to "call_pall 0x81". Since __builtin_trap () is a
noreturn function, no other instructions are emitted after call_pal.

However, when call_pal insn is executed, alpha updates program counter
before the signal is raised. As call_pal was the last insn, updated PC
points outside of the function boundaries, and backtrace (and gdb,
FWIW) failed to found enclosing function.

The solution is to emit nop after call_pal insn, so PC will always
remain between function boundaries.

Attached patch implements dumpregs function for alpha.

Bootstrapped and regression tested on alphaev68-linux-gnu, and also
checked that gdb and dumpregs produce the same register layout and
values.

Using both pathces, I get:

$ ./testprog Breakpoint
SIGTRAP: trace trap
PC=2199039251764 m=0 sigcode=0

goroutine 1 [running]:
runtime.Breakpoint
        /space/homedirs/uros/gcc-svn/trunk/libgo/go/runtime/proc.go:2862
main.Breakpoint
        /space/homedirs/uros/gcc-svn/trunk/libgo/go/runtime/testdata/testprog/deadlock.go:145
main.main
        /space/homedirs/uros/gcc-svn/trunk/libgo/go/runtime/testdata/testprog/main.go:34

v0  0x20000f41530
t0  0x120023f30
t1  0x200000ca328
t2  0x20000038000
t3  0x200002e7766
t4  0x40
t5  0x4
t6  0x1f
t7  0x3f
s0  0x20001f49fb9
s1  0x10
s2  0xc420004960
s3  0x0
s4  0x200017da6a8
s5  0x0
fp  0x20001f49df0
a0  0x11fffd4f4
a1  0x12000dd6c
a2  0x11fffd4fe
a3  0x1
a4  0x17
a5  0x3
t8  0x2000002e030
t9  0x1
t10 0x0
t11 0x20001f49b20
ra  0x120006a3c
t12 0x20000f41530
at  0x6974f985
gp  0x2000003e030
sp  0x20001f49df0
pc  0x20000f41534

Uros.