From patchwork Tue Nov 7 16:11:18 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Simon Marchi X-Patchwork-Id: 79339 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A9DAF385771C for ; Tue, 7 Nov 2023 16:11:36 +0000 (GMT) X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 12EF33858C36 for ; Tue, 7 Nov 2023 16:11:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 12EF33858C36 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=efficios.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=efficios.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 12EF33858C36 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699373484; cv=none; b=GY+3K5QzlthKLCWtKqnhHelV2e0w9iCFJht58292PNf6R+hNp3tVy9rp55cD61ulgqFH4BMwjp5zTQMHUpIGcJGoLAom4UfzQKGlHIgZK5oQk+WH+HC141kOaom5wLeTbM3sfT5zlzFPyWZrrB51/fqwxsf7YS15v6Ccj10UpMk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699373484; c=relaxed/simple; bh=cHyx0A0MXSLcB8ORGgQbvGUjR3v+r//K/NGR8n64jp8=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=P/qfhM6Mh9rvmbTH67B/fU2b2KyElCU4PjBQBXwj+XqgIjzuyS4gwu210WLA+8Vf+rTkQbW+IbbnUdR612pjYs8d4OLQZTp/4dKWWkIjgqnbfoUDoAUPoIQ5NKNOQ8EH/rZM0yCVBDmPaVhRyZzRDf1tJYmCGO5A5K0TwhyjEpA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from smarchi-efficios.internal.efficios.com (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) (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 ESMTPSA id 9BE381E00F; Tue, 7 Nov 2023 11:11:20 -0500 (EST) From: Simon Marchi To: gdb-patches@sourceware.org Cc: Simon Marchi Subject: [PATCH] gdb/arm: remove thumb bit in arm_adjust_breakpoint_address Date: Tue, 7 Nov 2023 11:11:18 -0500 Message-ID: <20231107161120.25679-1-simon.marchi@efficios.com> X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 X-Spam-Status: No, score=-3496.8 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_NONE, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_SOFTFAIL, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org 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+patchwork=sourceware.org@sourceware.org When compiling gdb with -fsanitize=address on ARM, I get a crash in test gdb.arch/arm-disp-step.exp, reproduced easily with: $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step -ex "break *test_call_end" Reading symbols from testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step... ================================================================= ==23295==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb4a14fd1 at pc 0x01a48871 bp 0xbeab8490 sp 0xbeab8494 Since it doesn't require running the program, it can be reproduced locally on a dev machine other than ARM, after acquiring the test binary. The length of the allocate buffer `buf` is 1, and we try to extract an integer of size 2 from it. The length of 1 comes from the subtraction `bpaddr - boundary`. Normally, on ARM, all instructions are aligned on a multiple of 2, so it's weird for this subtraction to result in 1. In this case, boundary comes from the result of find_pc_partial_function returning 0x549: (gdb) p/x bpaddr $2 = 0x54a (gdb) p/x boundary $3 = 0x549 (gdb) p/x bpaddr - boundary $4 = 0x1 0x549 is the address of the test_call_subr label, 0x548, with the thumb bit enabled. Before doing some math with the address, I think we need to strip the thumb bit, like is done elsewhere (for instance for bpaddr earlier in the same function). I wonder if find_pc_partial_function should do that itself, in order to return an address that is suitable for arithmetic. In any case, that would be a change with a broad impact, so for now just fix the issue locally. After the patch: $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step -ex "break *test_call_end" Reading symbols from testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step... Breakpoint 1 at 0x54a: file /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/arm-disp-step.S, line 103. Change-Id: I74fc458dbea0d2c1e1f5eadd90755188df089288 --- gdb/arm-tdep.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) base-commit: eab996435fe65a421541f59557c5f1fd427573a3 diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c index a9c43b27265e..d4047ddbb868 100644 --- a/gdb/arm-tdep.c +++ b/gdb/arm-tdep.c @@ -5337,9 +5337,12 @@ arm_adjust_breakpoint_address (struct gdbarch *gdbarch, CORE_ADDR bpaddr) bpaddr = gdbarch_addr_bits_remove (gdbarch, bpaddr); - if (find_pc_partial_function (bpaddr, NULL, &func_start, NULL) - && func_start > boundary) - boundary = func_start; + if (find_pc_partial_function (bpaddr, NULL, &func_start, NULL)) + { + func_start = gdbarch_addr_bits_remove (gdbarch, func_start); + if (func_start > boundary) + boundary = func_start; + } /* Search for a candidate IT instruction. We have to do some fancy footwork to distinguish a real IT instruction from the second