From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id DPhiOClOMmFdEwAAWB0awg (envelope-from ) for ; Fri, 03 Sep 2021 12:32:41 -0400 Received: by simark.ca (Postfix, from userid 112) id D7CF71EE22; Fri, 3 Sep 2021 12:32:41 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 1E3ED1EDDB for ; Fri, 3 Sep 2021 12:32:41 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9D7123847822 for ; Fri, 3 Sep 2021 16:32:40 +0000 (GMT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) by sourceware.org (Postfix) with ESMTPS id 2E7BE384B13A for ; Fri, 3 Sep 2021 16:32:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2E7BE384B13A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: by mail-io1-xd30.google.com with SMTP id a15so7457245iot.2 for ; Fri, 03 Sep 2021 09:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=tIytYfIgNymTbMYw+GKCvz7hR00YTfOi9WQaJ4oSpdo=; b=LCyvX0rD80kHnv9VgjdFPoi70vv/dAyFw25gCgy7UgoSB+ADEPkR5CCX8zeGWU2unv Urw4v0uCa7CjfKRSJmQB5tdf3WQYeSL9rBBCLpMO5ws6WdyJml3r1VFfnPhTGEPLK2sA EQPybQr2+8k6ZiZOVSxWnpjEM/toU5pZEkpYR6ufOKXgLlFfWIuUz+03b7TbPdtAbc4M MaBP9SMWtURAN3qOaAixBkmxgCuaTiNjgnmUXfhHNL/FPs0v1C+daDpgnwkzNZGdGqtE KySeWynsy1uxm4FRY6wCNrrZI6VK+xmPoVhDeZUPIdJ1/ezhV4Ice/iJ7s4ftZAc03t3 c58Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=tIytYfIgNymTbMYw+GKCvz7hR00YTfOi9WQaJ4oSpdo=; b=T+irXyAKhmc4X08FQTrzIzsvipDAqZoWhzCUBi8I5NjHn+v2349WPpxEocRTCPF4ra aYP3GLUne8TbMjRo+mVzatRobMPcWPSJBX8FodjwyVYD5lz/UdSfaCs2BhihkCTk//Kx anud3/CsSqnblenI1M8cmiyjU9/0mBWO7Bj6Me7kXHWU/agguMTyQFLmSnET2tb23ong EopiIboyZ6zI/NvaNjqSM8VSHKid4bdZvZQjiAT1s0GWQmDwXZWH4UAoR0yumxczrnsL Bn9qxBxgEy+fRIfKrjTAQj4hTSpwhA0B8NgMC5FVn5XGxXWcF0t7ditK/6u/sTELj3Ns 2Wdg== X-Gm-Message-State: AOAM532RUz8YYvuJFYtqxDGsqdhP2wQw4FYF4qbT6bMtPfn3lsMegnI6 EgzTcp5XgCh7/qhZStv+aDqP2dRQGVRVE7S8 X-Google-Smtp-Source: ABdhPJyRv3ERZosu4EQ0WvVzMw2PWlkGJGTOOksx8E6UMDeFXEyRXDjcMdhWL8qSNbMwIHjK9gJpxA== X-Received: by 2002:a6b:f203:: with SMTP id q3mr3749059ioh.32.1630686748530; Fri, 03 Sep 2021 09:32:28 -0700 (PDT) Received: from murgatroyd.Home (97-122-72-212.hlrn.qwest.net. [97.122.72.212]) by smtp.gmail.com with ESMTPSA id r18sm3022465ioa.13.2021.09.03.09.32.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Sep 2021 09:32:27 -0700 (PDT) From: Tom Tromey To: gdb-patches@sourceware.org Subject: [PATCH] Use CORE_ADDR as return type from x86_dr_low_get_addr Date: Fri, 3 Sep 2021 10:32:19 -0600 Message-Id: <20210903163219.2590419-1-tromey@adacore.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tom Tromey Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On a Windows build locally, watchpoints started failing. I tracked this down to x86_dr_low_get_addr returning an 'unsigned long'... in this particular build, this is a 32-bit type, but the inferior is a 64-bit program. This patch fixes the problem by changing the return type. No other change is really required, because this matches the function pointer in struct x86_dr_low_type. However, I found a spot in windows-nat.c that is a bit clearer if it uses CORE_ADDR as well, so I've also made this change. --- gdb/nat/x86-dregs.c | 2 +- gdb/windows-nat.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/gdb/nat/x86-dregs.c b/gdb/nat/x86-dregs.c index cf8e517eb0d..24751647005 100644 --- a/gdb/nat/x86-dregs.c +++ b/gdb/nat/x86-dregs.c @@ -52,7 +52,7 @@ x86_dr_low_set_addr (struct x86_debug_reg_state *new_state, int i) /* Return the inferior's debug register REGNUM. */ -static unsigned long +static CORE_ADDR x86_dr_low_get_addr (int i) { return x86_dr_low.get_addr (i); diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c index 0c2d55ef67b..b45de3cab7a 100644 --- a/gdb/windows-nat.c +++ b/gdb/windows-nat.c @@ -122,7 +122,7 @@ enum | CONTEXT_SEGMENTS | CONTEXT_DEBUG_REGISTERS \ | CONTEXT_EXTENDED_REGISTERS -static uintptr_t dr[8]; +static CORE_ADDR dr[8]; static int debug_registers_changed; static int debug_registers_used; @@ -3221,7 +3221,7 @@ cygwin_set_dr (int i, CORE_ADDR addr) static void cygwin_set_dr7 (unsigned long val) { - dr[7] = (CORE_ADDR) val; + dr[7] = val; debug_registers_changed = 1; debug_registers_used = 1; } -- 2.31.1