From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id uSZFEwV6vGlNyDAAWB0awg (envelope-from ) for ; Thu, 19 Mar 2026 18:34:45 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=pkaUi4hM; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=K+elHH2C; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=LrQVc8OW; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=BTG9degM; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 4A1981E08C; Thu, 19 Mar 2026 18:34:45 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id D3A921E08C for ; Thu, 19 Mar 2026 18:34:43 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 6FABE4C31822 for ; Thu, 19 Mar 2026 22:34:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6FABE4C31822 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=pkaUi4hM; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=K+elHH2C; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=LrQVc8OW; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=BTG9degM Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by sourceware.org (Postfix) with ESMTPS id 0547C4B196F9 for ; Thu, 19 Mar 2026 22:34:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0547C4B196F9 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0547C4B196F9 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.135.223.131 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773959651; cv=none; b=BBSbvhqXq0O4Mpw7sDjuAryDTDqEdB0Xp4L6rrGre6+BAeXl7ozWAu3s6A+A8Tv8yUn+lT5HCPDbFX5/TJteOHAFNU2jw2fGFFUqvgote5/9+qG09cUc53eDLwaryaTLkTzbS5PbUdHcgc8cP/1wnxN7K9M5j8mJbx2cTqDQFVM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773959651; c=relaxed/simple; bh=DB4sCwOgnXWyAGzzP4I1oFTTwCt/S3n9s6270rxLlck=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature: Message-ID:Date:MIME-Version:Subject:To:From; b=W/7+TCcSdRsHop52HTed4QJAUkOJtt9xmwJ4uZ86ENndeR3CwHAKExoLVqom+bYWz0cwtRi6R/1kAPYXTH3uL0vCUwGWMB4LHWYexAnCGmhmxTVjH1C3am5qTp5EHV9UyGm0DCIvPmKKQo+98SopoeXa2nWoJFWNdAS0zWOVGGQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0547C4B196F9 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id E63255BCF7; Thu, 19 Mar 2026 22:34:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1773959650; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=a3QX4h746NjcXZsDl9VP2uZfwLj9w0eF6FfEjs6vkhc=; b=pkaUi4hMsoCN0Z+SMZuW8yVW/DLYeBnIYrYQm8nN+hyXweftPxhT0d+CkHSzy/CbPcfo9S pvbrZdU8QnUIH5GuLeZpHyfklH4LRgspxztN20VjoX23tNeqV02SuQg9Dt56LMBNlcOMUC pP6v2ajX5GcIg3+cZHjUSomLtUJMRLA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1773959650; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=a3QX4h746NjcXZsDl9VP2uZfwLj9w0eF6FfEjs6vkhc=; b=K+elHH2CRZhClhwdvV3NdmcmAk4kjdiNJy9+VSpAQ7E+iBoqXtc2XZtviKXOWjrRF2qY1b LlGpWYWr+mRr+cBA== Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=LrQVc8OW; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=BTG9degM DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1773959648; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=a3QX4h746NjcXZsDl9VP2uZfwLj9w0eF6FfEjs6vkhc=; b=LrQVc8OWz5oQm2+YuluXZEOcdiCfwrJjl5MtfKTeOFODtiZAJAlByIrJ1UFoQOqkm+RFaY 2OjZVvjNuTNggGaVWO0ZbMQgEIjGwtHFE8fYq36Yci2FlXbKD5RAwF2PY8lqRNB86Wcj5R gJ+kiTS9D7pbxyZUMwRexCQwK2EXbOM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1773959648; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=a3QX4h746NjcXZsDl9VP2uZfwLj9w0eF6FfEjs6vkhc=; b=BTG9degMa1zxziVlODKesADw6FOLe5xWu51OaePfPmcV2pNm3MVlSFySY3ZZBHcMuEjfPj YRf2YMcFZ0iLCSCA== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C329B4273B; Thu, 19 Mar 2026 22:34:08 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id uvNCLuB5vGlnbAAAD6G6ig (envelope-from ); Thu, 19 Mar 2026 22:34:08 +0000 Message-ID: <22f19822-3ae3-4757-968d-18281486c3c1@suse.de> Date: Thu, 19 Mar 2026 23:34:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] [gdb/tdep] Fix unrelocated pc in i386_displaced_step_fixup To: "Schimpe, Christina" , Andrew Burgess , "gdb-patches@sourceware.org" References: <20260317071925.3543-1-tdevries@suse.de> <87h5qc577o.fsf@redhat.com> Content-Language: en-US From: Tom de Vries In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Action: no action X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Spamd-Result: default: False [-4.51 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; FROM_HAS_DN(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FUZZY_RATELIMITED(0.00)[rspamd.com]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[suse.de:+]; DNSWL_BLOCKED(0.00)[2a07:de40:b281:106:10:150:64:167:received,2a07:de40:b281:104:10:150:64:97:from]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; RCPT_COUNT_THREE(0.00)[3]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:dkim, suse.de:mid, suse.de:email, imap1.dmz-prg2.suse.org:helo, imap1.dmz-prg2.suse.org:rdns, intel.com:email] X-Rspamd-Queue-Id: E63255BCF7 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 3/19/26 6:40 PM, Schimpe, Christina wrote: >> -----Original Message----- >> From: Andrew Burgess >> Sent: Donnerstag, 19. März 2026 13:34 >> To: Tom de Vries ; gdb-patches@sourceware.org >> Subject: Re: [PATCH] [gdb/tdep] Fix unrelocated pc in >> i386_displaced_step_fixup >> >> >> Hi Tom, >> >> Thanks for fixing this. Just a couple of minor notes: >> >> Tom de Vries writes: >> >>> With test-case gdb.threads/next-fork-other-thread.exp and target board >>> unix/-m32 I run into: >>> ... >>> (gdb) next^M >>> [Switching to Thread 0xf643ab40 (LWP 3267939)]^M ^M Thread 5 >>> "next-fork-other" hit Breakpoint 1, main () at \ >>> next-fork-other-thread.c:73^M >>> 73 alarm (60);^M >>> (gdb) FAIL: $exp: fork_func=fork: target-non-stop=off: non-stop=off: \ >>> displaced-stepping=on: i=$n: next to break here ... >> >> Please can you clean up the log output to remove ^M line endings when >> quoting it in commit messages. Commit messages are written once, but read >> possibly multiple times, so it is right that we invest more effort when writing >> them in order to make them easier to read. Leaving the ^M endings in place >> just adds unnecessary noise. >> >>> >>> Before we go into how this happens, let's first look at the inferior. >>> >>> In main, 4 threads are started with the same thread function, leaving >>> all 5 threads in a loop: >>> - the main thread is stuck in a loop calling sleep, and gdb steps through this >>> loop using next >>> - the other, non-main threads are stuck in a loop where each thread: >>> - forks off a child process that exits immediately >>> - waits for the child process to exit >>> - calls sleep >>> >>> The FAIL happens as follows (following snippets from this gdb.log [1]). >>> >>> One of the non-main threads enters __syscall_cancel_arch to do a >>> sycall ( either to sleep, or to wait). >>> >>> Then the non-main thread stops: >>> ... >>> [infrun] handle_signal_stop: [2937316.2937324.0] hit another thread's \ >>> single-step breakpoint^M >>> [infrun] handle_signal_stop: delayed software breakpoint trap, ignoring^M >>> [infrun] switch_back_to_stepped_thread: need to step >> [2937316.2937324.0] \ >>> over single-step breakpoint^M >>> ... >>> because we "hit another thread's single-step breakpoint". >>> >>> AFAIU, this is because of the main thread stepping through >>> __syscall_cancel_arch. >>> >>> To handle this, we're going to try displaced stepping. >>> >>> The syscall instruction is copied: >>> ... >>> [displaced] displaced_step_prepare_throw: original insn 0xf7cdce69: \ >>> cd 80 int $0x80^M >>> [displaced] prepare: selected buffer at 0x80490d2^M ... >>> to a buffer at _start+2: >>> ... >>> 080490d0 <_start>: >>> 80490d0: 31 ed xor %ebp,%ebp >>> 80490d2: 5e pop %esi >>> ... >>> and we're going to resume execution there. >>> >>> However, right after resuming we get a GDB_SIGNAL_CHLD for the same >> thread. >>> >>> Part of handling that is finalizing the displaced stepping: >>> ... >>> [displaced] finish: restored 2937316.2937324.0 0x80490d2^M >>> [displaced] i386_displaced_step_fixup: fixup (0xf7cdce69, 0x80490d2), \ >>> insn = 0xcd 0x80 ...^M >>> [displaced] i386_displaced_step_fixup: syscall changed %eip; not >> relocating^M >>> [infrun] handle_signal_stop: stop_pc=0x80490d2^M ... >>> >>> The stop pc is 0x80490d2, the address of the copied instruction. In >>> other words, we've stopped without making progress. >>> >>> The problem is that the address is in the displaced stepping buffer, >>> and needs relocating, but instead we have "syscall changed %eip; not >> relocating". >>> >>> The code in i386_displaced_step_fixup doesn't recognize this situation: >>> ... >>> if (i386_syscall_p (insn, &insn_len) >>> && pc != to + (insn - insn_start) + insn_len >>> /* GDB can get control back after the insn after the syscall. >>> Presumably this is a kernel bug. >>> i386_displaced_step_copy_insn ensures it's a nop, >>> we add one to the length for it. */ >>> && pc != to + (insn - insn_start) + insn_len + 1) >>> displaced_debug_printf ("syscall changed %%eip; not relocating"); >>> ... >>> >>> It only handles the cases where the stop pc is: >>> - the address after the syscall insn, or >>> - the address after the nop after the syscall insn >>> >>> So, instead of relocating the stop pc back to the original 0xf7cdce69, >>> it stays 0x80490d2. After resuming at that address, the thread: >>> - executes the syscall, >>> - executes the rest of _start, >>> - enters main, and >>> - runs into the breakpoint at the start of main. >>> >>> Since commit cf141dd8ccd ("gdb: fix reg corruption from displaced >>> stepping on amd64"), we do handle the "pc == to" case in >> amd64_displaced_step_fixup: >>> ... >>> if (amd64_syscall_p (insn_details, &insn_len) >>> /* GDB can get control back after the insn after the syscall. >>> Presumably this is a kernel bug. Fixup ensures its a nop, we >>> add one to the length for it. */ >>> && (pc < to || pc > (to + insn_len + 1))) >>> displaced_debug_printf ("syscall changed %%rip; not relocating"); >>> ... >>> >>> Fix this in the same way. >>> >>> Tested on x86_64-linux, with target board unix/-m32. >>> >>> On openSUSE Tumbleweed (kernel version 6.19.7), this patch fixes the test- >> case. >>> >>> On openSUSE Leap 16.0 (kernel version 6.12.0), we still run into PR29040. >> >> I still see these failures: >> >> FAIL: gdb.threads/next-fork-other-thread.exp: fork_func=fork: target-non- >> stop=off: non-stop=off: displaced-stepping=auto: i=4: next to other line >> FAIL: gdb.threads/next-fork-other-thread.exp: fork_func=fork: target-non- >> stop=off: non-stop=off: displaced-stepping=on: i=2: next to other line >> FAIL: gdb.threads/next-fork-other-thread.exp: fork_func=fork: target-non- >> stop=off: non-stop=off: displaced-stepping=off: i=4: next to for loop >> >> The first two are described by PR gdb/29040, but the third is a different error >> message, but I don't know if the third failure is a consequence of the first two >> failures or not. Still I do think the fix you are proposing here is correct, so >> with the commit message cleaned >> up: >> >> Approved-By: Andrew Burgess >> >> Thanks, >> Andrew >> >>> >>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33997 >>> >>> [1] https://sourceware.org/bugzilla/attachment.cgi?id=16660 >>> --- >>> gdb/i386-tdep.c | 3 +-- >>> 1 file changed, 1 insertion(+), 2 deletions(-) >>> >>> diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c index >>> b9013e183c2..93357b41b10 100644 >>> --- a/gdb/i386-tdep.c >>> +++ b/gdb/i386-tdep.c >>> @@ -813,12 +813,11 @@ i386_displaced_step_fixup (struct gdbarch >> *gdbarch, >>> it unrelocated. Goodness help us if there are PC-relative >>> system calls. */ >>> if (i386_syscall_p (insn, &insn_len) >>> - && pc != to + (insn - insn_start) + insn_len >>> /* GDB can get control back after the insn after the syscall. >>> Presumably this is a kernel bug. >>> i386_displaced_step_copy_insn ensures it's a nop, >>> we add one to the length for it. */ >>> - && pc != to + (insn - insn_start) + insn_len + 1) >>> + && (pc < to || pc > to + (insn - insn_start) + insn_len + 1)) >>> displaced_debug_printf ("syscall changed %%eip; not relocating"); >>> else >>> { >>> >>> base-commit: 9cc83ec0ce9b4b75e8cd2b0c46f23d4cbf4b2f2b >>> -- >>> 2.51.0 >> > > Thank you for working on this. > > I cannot reproduce the issue(s), as I do not have that specific system available. > In any case, the fix makes sense to me. However, I am only adding my Reviewed-by > tag here as this is an area I do not yet feel completely confident about. > Andrew approved this anyways already (thanks!). So with the commit message fixed: > > Reviewed-By: Christina Schimpe Thanks both for the reviews, pushed. - Tom > Christina > Intel Deutschland GmbH > Registered Address: Dornacher Straße 1, 85622 Feldkirchen, Germany > Tel: +49 89 991 430, www.intel.de > Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell > Chairperson of the Supervisory Board: Nicole Lau > Registered Seat: Munich > Commercial Register: Amtsgericht München HRB 186928