public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Keith Seitz <keiths@redhat.com>
To: John Baldwin <jhb@FreeBSD.org>, gdb-patches@sourceware.org
Subject: Re: [PATCH v6 00/15] Handle variable XSAVE layouts
Date: Tue, 25 Jul 2023 10:17:02 -0700	[thread overview]
Message-ID: <c9650000-cfff-3466-92ac-9877caeb81da@redhat.com> (raw)
In-Reply-To: <20230714155151.21723-1-jhb@FreeBSD.org>

Hi,

On 7/14/23 08:51, John Baldwin wrote:
> Changes since V5:
> 
> - A few fixes not tied to the new layout handling have been merged to
>    master.
> 
> - Reworded the comment describing i386_*_core_read_xsave_info in patches
>    6 and 8.
> 

I am sorry I am late to the review here, but I've been testing Sapphire
Rapids this past week (and its expanded register save area), and thought
I would dig into this a bit, testing it on random x86 systems in our (internal)
test farm.
  
The (unsurprising) good news is that on RHEL9, this series does not adversely
affect regression testing results on ppc64le, aarch64, or s390x. It also
greatly improves results on Sapphire Rapids CPUs (at least on the native
unix target).

However, I've run into some pretty consistent problems which I have not yet begun to
investigate (likely all the same bug).

With either a Raptor Lake CPU ("13th Gen Intel(R) Core(TM) i7-13700") or Sapphire
Rapids ("Intel(R) Xeon(R) Gold 5418Y"), I can get gdb to consistently segfault in
memcpy in several tests using gdbserver w/-m32:

$ make check RUNTESTFLAGS="--target_board native-gdbserver/-m32" TESTS=gdb.base/auxv.exp
[snip]
		=== gdb Summary ===

# of expected passes		6
# of unexpected failures	1
# of unresolved testcases	5
# of unsupported tests		3

 From gdb.log:

(gdb) PASS: gdb.base/auxv.exp: info auxv on live process
gcore /root/test-fsf-master/gdb/build-x86_64-redhat-linux-gnu/gdb/testsuite/outputs/gdb.base/auxv/auxv.gcore


Fatal signal: Segmentation fault
----- Backtrace -----
0x55ef54b9acda gdb_internal_backtrace_1
         ../../gdb/bt-utils.c:122
0x55ef54b9acda _Z22gdb_internal_backtracev
         ../../gdb/bt-utils.c:168
0x55ef54b9acda _Z22gdb_internal_backtracev
         ../../gdb/bt-utils.c:154
0x55ef54cc086e handle_fatal_signal
         ../../gdb/event-top.c:889
0x55ef54cc0a78 handle_sigsegv
         ../../gdb/event-top.c:962
0x7fd237654dcf ???
0x55ef54d4e9bf memcpy
         /usr/include/bits/string_fortified.h:29
0x55ef54d4e9bf _Z18i387_collect_xsavePK8regcacheiPvi
         ../../gdb/i387-tdep.c:1543
0x55ef54d062c8 gcore_elf_collect_regset_section_cb
         ../../gdb/gcore-elf.c:85
0x55ef54d057ac gcore_elf_collect_thread_registers
         ../../gdb/gcore-elf.c:121
0x55ef54d057ac _Z37gcore_elf_build_thread_register_notesP7gdbarchP11thread_info10gdb_signalP3bfdPSt10unique_ptrIcN3gdb13xfree_deleterIcEEEPi
         ../../gdb/gcore-elf.c:135
0x55ef54db378f linux_corefile_thread
         ../../gdb/linux-tdep.c:1846
0x55ef54db3aec linux_make_corefile_notes
         ../../gdb/linux-tdep.c:2102
0x55ef54d06777 _Z27gdbarch_make_corefile_notesP7gdbarchP3bfdPi
         ../../gdb/gdbarch.c:3743
0x55ef54d06777 write_gcore_file_1
         ../../gdb/gcore.c:82
0x55ef54d070f7 _Z16write_gcore_fileP3bfd
         ../../gdb/gcore.c:119
0x55ef54d070f7 gcore_command
         ../../gdb/gcore.c:157
0x55ef54be0fe4 _Z8cmd_funcP16cmd_list_elementPKci
         ../../gdb/cli/cli-decode.c:2735
0x55ef54fca4b0 _Z15execute_commandPKci
         ../../gdb/top.c:574
0x55ef54cc91b7 _Z15command_handlerPKc
         ../../gdb/event-top.c:552
0x55ef54cc9263 _Z20command_line_handlerOSt10unique_ptrIcN3gdb13xfree_deleterIcEEE
         ../../gdb/event-top.c:788
0x55ef54cc048c gdb_rl_callback_handler
         ../../gdb/event-top.c:259
0x7fd2384c65bd ???
0x55ef54cc6a1a gdb_rl_callback_read_char_wrapper_noexcept
         ../../gdb/event-top.c:195
0x55ef54cc6c03 gdb_rl_callback_read_char_wrapper
         ../../gdb/event-top.c:234
0x55ef54fedc6f stdin_event_handler
         ../../gdb/ui.c:155
0x55ef551c5f2d gdb_wait_for_event
         ../gdbsupport/../../gdbsupport/event-loop.cc:694
0x55ef551c5f2d gdb_wait_for_event
         ../gdbsupport/../../gdbsupport/event-loop.cc:585
0x55ef5522c227 _Z16gdb_do_one_eventi.constprop.0
         ../gdbsupport/../../gdbsupport/event-loop.cc:264
0x55ef54dc8634 start_event_loop
         ../../gdb/main.c:412
0x55ef54dc8634 captured_command_loop
         ../../gdb/main.c:476
0x55ef54aaee2c captured_main
         ../../gdb/main.c:1320
0x55ef54aaee2c _Z8gdb_mainP18captured_main_args
         ../../gdb/main.c:1339
0x55ef54aaee2c main
         ../../gdb/gdb.c:32
---------------------
A fatal error internal to GDB has been detected, further
debugging is not possible.  GDB will now terminate.

This is a bug, please report it.  For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.

ERROR: GDB process no longer exists

A complete list of affected tests:

gdb.base/auxv.exp
gdb.base/coredump-filter.exp
gdb.base/corefile2.exp
gdb.base/gcore-tls-pie.exp
gdb.base/gcore.exp
gdb.base/info-proc.exp
gdb.base/patch.exp
gdb.base/print-symbol-loading.exp
gdb.base/siginfo-obj.exp
gdb.base/siginfo-thread.exp
gdb.base/solib-search.exp
gdb.base/vdso-warning.exp
gdb.btrace/gcore.exp
gdb.python/py-strfns.exp
gdb.reverse/break-precsave.exp
gdb.reverse/consecutive-precsave.exp
gdb.reverse/finish-precsave.exp
gdb.reverse/i386-precsave.exp
gdb.reverse/machinestate-precsave.exp
gdb.reverse/sigall-precsave.exp
gdb.reverse/solib-precsave.exp
gdb.reverse/step-precsave.exp
gdb.reverse/until-precsave.exp
gdb.threads/tls-core.exp same

The unix/-m32 target does not exhibit these problems. Just the
gdbserver targets (native-gdbserver, native-extended-gdbserver).

On my personal machine, a Comet Lake, all of these tests work/pass.

Keith


  parent reply	other threads:[~2023-07-25 17:17 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-14 15:51 John Baldwin
2023-07-14 15:51 ` [PATCH v6 01/15] x86: Add an x86_xsave_layout structure to handle " John Baldwin
2023-07-26 19:22   ` Simon Marchi
2023-07-26 21:27     ` John Baldwin
2023-07-26 22:51       ` Simon Marchi
2023-07-14 15:51 ` [PATCH v6 02/15] gdb: Store an x86_xsave_layout in i386_gdbarch_tdep John Baldwin
2023-07-14 15:51 ` [PATCH v6 03/15] core: Support fetching x86 XSAVE layout from architectures John Baldwin
2023-07-26 19:37   ` Simon Marchi
2023-07-26 21:28     ` John Baldwin
2023-07-14 15:51 ` [PATCH v6 04/15] nat/x86-cpuid.h: Add x86_cpuid_count wrapper around __get_cpuid_count John Baldwin
2023-07-26 19:41   ` Simon Marchi
2023-07-14 15:51 ` [PATCH v6 05/15] x86 nat: Add helper functions to save the XSAVE layout for the host John Baldwin
2023-07-26 19:48   ` Simon Marchi
2023-07-26 21:37     ` John Baldwin
2023-07-14 15:51 ` [PATCH v6 06/15] gdb: Update x86 FreeBSD architectures to support XSAVE layouts John Baldwin
2023-07-26 20:04   ` Simon Marchi
2023-07-26 21:43     ` John Baldwin
2023-07-28 21:23   ` [PATCH v6a " John Baldwin
2023-08-28 16:01     ` Simon Marchi
2023-07-14 15:51 ` [PATCH v6 07/15] gdb: Support XSAVE layouts for the current host in the FreeBSD x86 targets John Baldwin
2023-07-26 20:26   ` Simon Marchi
2023-07-14 15:51 ` [PATCH v6 08/15] gdb: Update x86 Linux architectures to support XSAVE layouts John Baldwin
2023-07-26 20:45   ` Simon Marchi
2023-07-26 21:16     ` John Baldwin
2023-07-27 21:48       ` Simon Marchi
2023-07-28 16:30         ` John Baldwin
2023-07-28 17:58           ` Simon Marchi
2023-07-28 21:30             ` John Baldwin
2023-07-28 21:29   ` [PATCH v6a " John Baldwin
2023-08-14 17:52     ` John Baldwin
2023-08-28 16:21     ` Simon Marchi
2023-07-14 15:51 ` [PATCH v6 09/15] gdb: Support XSAVE layouts for the current host in the Linux x86 targets John Baldwin
2023-07-26 20:51   ` Simon Marchi
2023-07-14 15:51 ` [PATCH v6 10/15] gdb: Use x86_xstate_layout to parse the XSAVE extended state area John Baldwin
2023-08-28 16:34   ` Simon Marchi
2023-07-14 15:51 ` [PATCH v6 11/15] gdbserver: Add a function to set the XSAVE mask and size John Baldwin
2023-08-28 16:46   ` Simon Marchi
2023-07-14 15:51 ` [PATCH v6 12/15] gdbserver: Refactor the legacy region within the xsave struct John Baldwin
2023-08-28 16:50   ` Simon Marchi
2023-08-28 17:32     ` John Baldwin
2023-07-14 15:51 ` [PATCH v6 13/15] gdbserver: Use x86_xstate_layout to parse the XSAVE extended state area John Baldwin
2023-08-28 18:15   ` Simon Marchi
2023-08-28 18:37     ` John Baldwin
2023-07-14 15:51 ` [PATCH v6 14/15] x86: Remove X86_XSTATE_SIZE and related constants John Baldwin
2023-08-28 20:38   ` Simon Marchi
2023-07-14 15:51 ` [PATCH v6 15/15] gdbserver: Simplify handling of ZMM registers John Baldwin
2023-08-28 20:57   ` Simon Marchi
2023-07-14 15:58 ` [PATCH v6 00/15] Handle variable XSAVE layouts John Baldwin
2023-07-26  8:31   ` Willgerodt, Felix
2023-07-25 17:17 ` Keith Seitz [this message]
2023-07-25 18:15   ` John Baldwin
2023-07-25 18:43     ` Keith Seitz
2023-07-25 18:59       ` John Baldwin
2023-07-25 20:42         ` Keith Seitz
2023-07-25 22:05           ` John Baldwin
2023-07-26 22:31             ` John Baldwin
2023-07-27 21:36               ` Keith Seitz
2023-07-28 16:35                 ` John Baldwin

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=c9650000-cfff-3466-92ac-9877caeb81da@redhat.com \
    --to=keiths@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jhb@FreeBSD.org \
    /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).