Running tests: could not set hardware breakpoint: invalid argument

[pnasrat]

I'm happy to try figure this out.
Steps to reproduce - I'm using GCE to run in on centos 7 image.

1. cd proctl
2. go test -c .
3. ./proctl.test -test.run=TestStep

Output:

--- FAIL: TestStep (0.17s)
    proctl_test.go:52: Break() : could not set hardware breakpoint: invalid argument
FAIL

$ cat /etc/redhat-release
CentOS Linux release 7.0.1406 (Core)
$ rpm -q glibc
glibc-2.17-55.el7_0.3.x86_64
$ uname -a
Linux delve01 3.10.0-123.13.1.el7.x86_64 #1 SMP Tue Dec 9 23:06:09 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ go version
go version go1.4.1 linux/amd64
# at commit 46e5cfd39963a489f6e4fc43ad3a9f78b9f5321b

strace -o trace.out -s 2048   ./proctl.test -test.run=TestStep
grep ptrace trace.out
ptrace(PTRACE_SETOPTIONS, 11858, 0, PTRACE_O_TRACECLONE) = 0
ptrace(PTRACE_POKEUSER, 11858, offsetof(struct user, u_debugreg), 0x400c30) = 0
ptrace(PTRACE_POKEUSER, 11858, offsetof(struct user, u_debugreg) + 56, 0x9) = -1 EINVAL (Invalid argument)

Using gdb I can see

(gdb) break breakpoints_linux_amd64.go:155
(gdb) run
Breakpoint 1, github.com/derekparker/delve/proctl.setHardwareBreakpoint (reg=0, tid=13764, addr=4197424, ~r3=...)
    at /home/pnasrat/go/src/github.com/derekparker/delve/proctl/breakpoints_linux_amd64.go:155
155     return PtracePokeUser(tid, dr7addr, dr7)
(gdb) p dr7
$1 = 9
(gdb) p dr7addr
$2 = 904

[pnasrat]

I wonder if we should be looking up dr7 with PEEKUSR - see for example

http://lxr.free-electrons.com/source/tools/testing/selftests/breakpoints/breakpoint_test.c#L84

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/gdbserver/linux-x86-low.c;h=2c3fccca8118a98bce500faa9d82e8e40c18ea57;hb=HEAD#l533

[derekparker]

Hmm.. we likely should be reading the original value in order to preserve the control bits set for other regs aside from the one we are currently setting - however I'm not sure if this is what is causing the failure above.

Along with this is a bug of the current implementation - it currently is setting dr7 bits for the base register DR0, and is not setting the values correctly for DR1-3.

[pnasrat]

If you're happy to wait a bit I can try come up with a fix over weekend/Monday, else happy to test proposed fixes

[derekparker]

Check out http://en.wikipedia.org/wiki/X86_debug_register#DR7_-_Debug_control for more info on what I described above, also you may want to have a look at the intel manual: http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-system-programming-manual-325384.pdf specifically chapter 17.

[derekparker]

@pnasrat yeah definitely, that's no problem.

[ebfe]

Maybe an alignment issue? The hw breakpoints are set with DR_LEN_8 which I
seem to remember requires the address to be 8-byte aligned.

Here's my attempt to fix this, enable dr1-dr3 usage and to generally be more
careful with the control bits ebfe/delve@c0b84352f1

[pnasrat]

I can confirm that at ebfe/delve@c0b8435 when I run

go test -v .

On the box in question it all passes - I suggest you amend the commit message to add a fixes line in the commit for this issue as per

https://help.github.com/articles/closing-issues-via-commit-messages/

before sending the pull request. Thanks, sorry not to have had time this evening to look at.