Skip to content

runtime: TestGdbPython fails on ppc64 #10017

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
rsc opened this issue Feb 26, 2015 · 2 comments
Closed

runtime: TestGdbPython fails on ppc64 #10017

rsc opened this issue Feb 26, 2015 · 2 comments
Labels
FrozenDueToAge
Milestone
Go1.5

Comments

@rsc
Copy link
Contributor

rsc commented Feb 26, 2015

TestGdbPython fails on the ppc64le builder. Don't know what the failure means.
http://build.golang.org/log/d81ea75267328ddf3441a74c92bc930679b9b69f

--- FAIL: TestGdbPython (0.42s)
    runtime-gdb_test.go:103: print mapvar failed: No symbol "mapvar" in current context.
FAIL
FAIL    runtime 19.616s

Turning off. Might be nice to understand for Go 1.5 but not terribly concerned.
@rsc rsc added this to the Go1.5Maybe milestone Feb 26, 2015
rsc added a commit that referenced this issue Feb 26, 2015
@rsc
runtime: disable TestGdbPython on ppc64
a5eda13 
(issue #10017)

Change-Id: Ia1267dfdb4474247926a998e32d9c6520015757d
Reviewed-on: https://go-review.googlesource.com/6130
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
@minux
Copy link
Member

minux commented Feb 26, 2015

The reason is that when you break on 'main.finish', gdb breaks on
the finish's frame, and because gdb can't backtrace our stack frames
on RISC architectures, the 'up' command will go to the wrong frame,
so mapvar can't be found there.

At least this is the reason for #10002, as I don't have access to
ppc64le systems to verify my hypothesis.

However, if we say break main.go:10 so that the breakpoint in the
the 'main.main' frame, then gdb can indeed print the correct map
out.

The easiest way to fix the gdb backtrace problem is to use
frame pointers like what we did with the framepointer experiment
on amd64. I'm not sure if we can write a python helper to unwind
the stack for gdb, is that possible? Interpreting our pclntab in Python
is at least simpler than interpreting that in DWARF. Or we can
use our spadj to generate cfa pseudo-instructions for gdb to
unwind the stack. @ianlancetaylor

@jankratochvil
Copy link
Contributor

I did not test it on ppc64 but hopefully the FAIL gets fixed by: https://go-review.googlesource.com/#/c/6267/

@minux minux closed this as completed in cb37cfa Mar 1, 2015
@mikioh mikioh changed the title misc/gdb: TestGdbPython fails on ppc64 runtime: TestGdbPython fails on ppc64 Mar 1, 2015
@mikioh mikioh modified the milestones: Go1.5Maybe, Go1.5 Mar 5, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.5
Development

No branches or pull requests
5 participants
@mikioh @rsc @minux @jankratochvil @gopherbot