From: Simon Marchi <simark@simark.ca>
To: Kevin Buettner <kevinb@redhat.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH v2] Disable record btrace bts support for AMD processors
Date: Thu, 14 May 2020 19:07:06 -0400 [thread overview]
Message-ID: <f9299c7f-4e53-7f81-1901-e59c407ec263@simark.ca> (raw)
In-Reply-To: <20200514220326.1403927-1-kevinb@redhat.com>
On 2020-05-14 6:03 p.m., Kevin Buettner via Gdb-patches wrote:
> [Note: The actual patch for v2 is unchanged. I've fixed a mistake
> in the commit log and expanded it a bit too.]
>
> Some Intel processors implement a Branch Trace Store (BTS) which GDB
> uses for reverse execution support via the "record btrace bts"
> command.
>
> I have been unable to find a description of a similar feature in a
> recent (April 2020) AMD64 architecture reference:
>
> https://www.amd.com/system/files/TechDocs/40332.pdf
>
> While it is the case that AMD processors have an LBR (last branch
> record) bit in the DebugCtl MSR, it seems that it affects only four
> MSRs when enabled. The names of these MSRs are LastBranchToIP,
> LastBranchFromIP, LastIntToIP, and LastIntFromIP. I can find no
> mention of anything more extensive. While looking at an Intel
> architecture document, I noticed that Intel's P6 family from the
> mid-90s had registers of the same name.
>
> Therefore...
>
> This commit disables "record btrace bts" support in GDB for AMD
> processors.
>
> Using the test case from gdb.base/break.exp, the sessions
> below show the expected behavior (run on a machine with an
> Intel processor) versus that on a machine with an AMD processor.
> The AMD processor in question is reported as follows by "lscpu":
> AMD Ryzen Threadripper 2950X 16-Core Processor . Finally, I'll
> note that the AMD machine is actually a VM, but I see similar
> behavior on both the virtualization host and the VM.
>
> Intel machine - Desired behavior:
>
> [kevinb@mohave gdb]$ ./gdb -q testsuite/outputs/gdb.base/break/break
> Reading symbols from testsuite/outputs/gdb.base/break/break...
> (gdb) start
> Temporary breakpoint 1 at 0x401179: file /home/kevinb/sourceware-git/native-build/bld/../../binutils-gdb/gdb/testsuite/gdb.base/break.c, line 43.
> Starting program: /home/kevinb/sourceware-git/native-build/bld/gdb/testsuite/outputs/gdb.base/break/break
>
> Temporary breakpoint 1, main (argc=1, argv=0x7fffffffd748, envp=0x7fffffffd758)
> at /home/kevinb/sourceware-git/native-build/bld/../../binutils-gdb/gdb/testsuite/gdb.base/break.c:43
> 43 if (argc == 12345) { /* an unlikely value < 2^16, in case uninited */ /* set breakpoint 6 here */
> (gdb) record btrace
> (gdb) b factorial
> Breakpoint 2 at 0x40121b: file /home/kevinb/sourceware-git/native-build/bld/../../binutils-gdb/gdb/testsuite/gdb.base/break.c, line 63.
> (gdb) c
> Continuing.
>
> Breakpoint 2, factorial (value=6)
> at /home/kevinb/sourceware-git/native-build/bld/../../binutils-gdb/gdb/testsuite/gdb.base/break.c:63
> 63 if (value > 1) { /* set breakpoint 7 here */
> (gdb) info record
> Active record target: record-btrace
> Recording format: Branch Trace Store.
> Buffer size: 64kB.
> Recorded 768 instructions in 22 functions (0 gaps) for thread 1 (process 19215).
> (gdb) record function-call-history
> 13 do_lookup_x
> 14 _dl_lookup_symbol_x
> 15 _dl_fixup
> 16 _dl_runtime_resolve_xsavec
> 17 atoi
> 18 strtoq
> 19 ____strtoll_l_internal
> 20 atoi
> 21 main
> 22 factorial
> (gdb) record instruction-history
> 759 0x00007ffff7ce0917 <____strtoll_l_internal+647>: pop %r15
> 760 0x00007ffff7ce0919 <____strtoll_l_internal+649>: retq
> 761 0x00007ffff7cdd064 <atoi+20>: add $0x8,%rsp
> 762 0x00007ffff7cdd068 <atoi+24>: retq
> 763 0x00000000004011b1 <main+75>: mov %eax,%edi
> 764 0x00000000004011b3 <main+77>: callq 0x401210 <factorial>
> 765 0x0000000000401210 <factorial+0>: push %rbp
> 766 0x0000000000401211 <factorial+1>: mov %rsp,%rbp
> 767 0x0000000000401214 <factorial+4>: sub $0x10,%rsp
> 768 0x0000000000401218 <factorial+8>: mov %edi,-0x4(%rbp)
>
> AMD machine - Wrong behavior:
>
> [kev@f32-1 gdb]$ ./gdb -q testsuite/outputs/gdb.base/break/break
> Reading symbols from testsuite/outputs/gdb.base/break/break...
> (gdb) start
> Temporary breakpoint 1 at 0x401179: file /ironwood1/sourceware-git/f32-master/bld/../../worktree-master/gdb/testsuite/gdb.base/break.c, line 43.
> Starting program: /mesquite2/sourceware-git/f32-master/bld/gdb/testsuite/outputs/gdb.base/break/break
>
> Temporary breakpoint 1, main (argc=1, argv=0x7fffffffd5b8, envp=0x7fffffffd5c8)
> at /ironwood1/sourceware-git/f32-master/bld/../../worktree-master/gdb/testsuite/gdb.base/break.c:43
> 43 if (argc == 12345) { /* an unlikely value < 2^16, in case uninited */ /* set breakpoint 6 here */
> (gdb) record btrace
> (gdb) b factorial
> Breakpoint 2 at 0x40121b: file /ironwood1/sourceware-git/f32-master/bld/../../worktree-master/gdb/testsuite/gdb.base/break.c, line 63.
> (gdb) c
> Continuing.
>
> Breakpoint 2, factorial (value=6)
> at /ironwood1/sourceware-git/f32-master/bld/../../worktree-master/gdb/testsuite/gdb.base/break.c:63
> 63 if (value > 1) { /* set breakpoint 7 here */
> (gdb) info record
> Active record target: record-btrace
> Recording format: Branch Trace Store.
> Buffer size: 64kB.
> warning: Recorded trace may be incomplete at instruction 7737 (pc = 0x405000).
> warning: Recorded trace may be incomplete at instruction 7739 (pc = 0x0).
> Recorded 7740 instructions in 46 functions (2 gaps) for thread 1 (process 1402911).
> (gdb) record function-call-history
> 37 ??
> 38 values
> 39 some_enum_global
> 40 ??
> 41 some_union_global
> 42 some_variable
> 43 ??
> 44 [decode error (2): unknown instruction]
> 45 ??
> 46 [decode error (2): unknown instruction]
> (gdb) record instruction-history
> 7730 0x0000000000404ff3: add %al,(%rax)
> 7731 0x0000000000404ff5: add %al,(%rax)
> 7732 0x0000000000404ff7: add %al,(%rax)
> 7733 0x0000000000404ff9: add %al,(%rax)
> 7734 0x0000000000404ffb: add %al,(%rax)
> 7735 0x0000000000404ffd: add %al,(%rax)
> 7736 0x0000000000404fff: .byte 0x0
> 7737 0x0000000000405000: Cannot access memory at address 0x405000
>
> Lastly, I'll note that I see a lot of gdb.btrace failures without
> this commit. Worse still, the results aren't always the same which
> causes a lot of noise when comparing test results.
>
> gdbsupport/ChangeLog:
>
> * btrace-common.h (btrace_cpu_vendor): Add CV_AMD.
>
> gdb/ChangeLog:
>
> * nat/linux-btrace.c (btrace_this_cpu): Add check for AMD
> processors.
> (cpu_supports_bts): Add CV_AMD case.
Thanks, this version and your other reply answer my questions.
Simon
next prev parent reply other threads:[~2020-05-14 23:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-14 22:03 Kevin Buettner
2020-05-14 23:07 ` Simon Marchi [this message]
2020-05-15 1:00 ` Kevin Buettner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f9299c7f-4e53-7f81-1901-e59c407ec263@simark.ca \
--to=simark@simark.ca \
--cc=gdb-patches@sourceware.org \
--cc=kevinb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).