From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by sourceware.org (Postfix) with ESMTPS id B14FD3858D3C for ; Fri, 22 Dec 2023 13:33:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B14FD3858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B14FD3858D3C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::333 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703252010; cv=none; b=cP64kcpacLHmDra17lPIW+mLZnPpHJm0L+E98ZZUGsYfJulD6b3DrvMxZWWlKDrLNta8TPZS7ZKlYQTrhbRE0pL6jCYnJxnt4yo4+7cWdxaiRRyK+GKRxOVjw5jQ073aQW5bh3fcaghDDYX7GGyxkUOZmhIkp5eM6SFT7cwym/I= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703252010; c=relaxed/simple; bh=C4JhPvgYJWJAwjUKJDtFmqRCNriIjfJQP9CXMEuDLEg=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=EEeRFPWKJi1hO7QC9RzghozLlO6isk/6c1EIbuWhcezLB6lt+V672RbZaeyzEiUBQQkJJhZgwMlxx2KG7MGToGGwYOB4s94OLcBHzhUMcAplChutF06U2mGbjDHloopNzgGd+4ooSWmb//pwaNlCJN4h/BliVP013LKbeKhw5vM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-40c60dfa5bfso20158725e9.0 for ; Fri, 22 Dec 2023 05:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1703252007; x=1703856807; darn=sourceware.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=6Y3k/ijQXu4tKpiSXs1Z0O4sa9icdwmAd9wPbNow+2I=; b=iSGXVaHiw3x3AXWxBt3eyMUA+jQsDusD0hjRQlCiyzAG4YPBYuXlIf+5ftxEdNuoQK spWg2uHvEo8AgIaAg30MqLZ+1gw0srwHxC1vBwcq3AvvW17gQUZdZrfZ4EeUQczNINQ9 cWxlxAqTbfbLzjlTWGbtkxdUoY5kARi0iCTCS2MPDHB/s2fUzHTfg81//MRtJLCaUP1M hkLWDotumCQRXUehc2tfeQafa8nC8UQUO88PeWoNo8YYyaQMGiFDIeZgW81lsRSKVx/5 euXIJeUJTrdNtsDE6WX9yeUWXqJwCZvuc7vcI4CfFe8682uWiQ7G4cytrdIewuD3f3ai M2mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703252007; x=1703856807; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6Y3k/ijQXu4tKpiSXs1Z0O4sa9icdwmAd9wPbNow+2I=; b=NPnAI5Wpjrv81mGOslnczvlcZeZos1GIvgpAjTQh6hj96U8G98BC9Srj4hPaeDUoes MzhkooZ1CL5q6TAYAj7F1RY7hvEViDl15jHzVckgwmP/SPG2u2NGk5HkKslkv2G1oMNS FCcWJoeAP0z7VPhpNE1uuoowQHiRpVg1Ez66w+f97uGjv2meGt/VZj9eqxTJakTw2SXm Wfakav8rLVPBzz92Xu8e2Wdg0qcF5vsv5zPjFCv44HeZRoHnfszaBKhqM5Hm0qU0yak7 KrAPdFWVy/Ya5Oo0ow8B0ussZzlABu86hQbzL9spKifvLZq9NHFHvGIGJaBOcamgUdzM 3kxQ== X-Gm-Message-State: AOJu0YyZhMXpxzqfVsIBT0lvE2v4Lzzrb8eIitW0U+QbFkzKB50UVkXY DfQHUxc6VbHbb1OjGOejI80oshnjDmJx X-Google-Smtp-Source: AGHT+IHZ0LW7XY87sJsLtSZCRUGuUAaWUqnLroHvrns9pGY2jtyntrPGwV+OD79HvvO5edIM7QFjLA== X-Received: by 2002:a7b:ca55:0:b0:40d:4908:277a with SMTP id m21-20020a7bca55000000b0040d4908277amr406355wml.131.1703252007317; Fri, 22 Dec 2023 05:33:27 -0800 (PST) Received: from legouguec-Precision-7550 ([2a01:e0a:253:fe0:21a4:95:3538:28ff]) by smtp.gmail.com with ESMTPSA id n42-20020a05600c502a00b0040b3d8907fesm6977713wmr.29.2023.12.22.05.33.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Dec 2023 05:33:23 -0800 (PST) From: =?utf-8?Q?K=C3=A9vin_Le_Gouguec?= To: Simon Marchi Cc: gdb-patches@sourceware.org, Luis Machado , John Baldwin , "Aktemur, Tankut Baris" Subject: Re: [PATCH 12/24] gdb: make get_frame_register_bytes take the next frame In-Reply-To: <20231201162751.741751-13-simon.marchi@efficios.com> (Simon Marchi's message of "Fri, 1 Dec 2023 11:27:25 -0500") References: <20231201162751.741751-1-simon.marchi@efficios.com> <20231201162751.741751-13-simon.marchi@efficios.com> Date: Fri, 22 Dec 2023 14:33:14 +0100 Message-ID: <87bkaiz7j9.fsf@adacore.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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 List-Id: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hey Simon! Simon Marchi writes: > Similar to the previous patches, change get_frame_register_bytes to take > the "next frame" instead of "this frame". > > Change-Id: Ie8f35042bfa6e93565fcefaee71b6b3903f0fe9f > Reviewed-By: John Baldwin > --- > gdb/dwarf2/expr.c | 22 +++++++++++----------- > gdb/frame.c | 16 ++++++---------- > gdb/frame.h | 10 +++++----- > gdb/i386-tdep.c | 8 ++++---- > gdb/i387-tdep.c | 10 +++++----- > gdb/ia64-tdep.c | 9 ++++----- > gdb/m68k-tdep.c | 10 +++++----- > gdb/mips-tdep.c | 7 ++++--- > gdb/rs6000-tdep.c | 10 +++++----- > gdb/valops.c | 3 +-- > 10 files changed, 50 insertions(+), 55 deletions(-) > [=E2=80=A6] > diff --git a/gdb/rs6000-tdep.c b/gdb/rs6000-tdep.c > index c43039302bc3..643997e5bd7d 100644 > --- a/gdb/rs6000-tdep.c > +++ b/gdb/rs6000-tdep.c > @@ -2713,11 +2713,11 @@ rs6000_register_to_value (frame_info_ptr frame, > fpr to vsr. */ > regnum =3D ieee_128_float_regnum_adjust (gdbarch, type, regnum); >=20=20 > - if (!get_frame_register_bytes (frame, regnum, 0, > - gdb::make_array_view (from, > - register_size (gdbarch, > - regnum)), > - optimizedp, unavailablep)) > + auto from_view > + =3D gdb::make_array_view (from, register_size (gdbarch, regnum)); > + frame_info_ptr next_frame =3D get_next_frame_sentinel_okay (frame); > + if (!get_frame_register_bytes (frame, regnum, 0, from_view, optimizedp, ^^^^^ Should this have been changed to 'next_frame', as the commit message suggests, and as was done in the other *-tdep.c? Asking because I'm observing a regression on ppc-linux in our internal testsuite. I've reproduced that regression with the O2_float_param testcase: cd gdb/testsuite/gdb.ada/O2_float_param powerpc-linux-gnu-gnatmake foo.adb \ -cargs -g -O2 -bargs -static -largs -static scp foo $TARGET: [=E2=80=A6gdb=E2=80=A6] foo \ -batch \ -ex 'tbreak callee.increment' \ -ex 'target remote | ssh gdbserver - foo' \ -ex continue Expected: > Temporary breakpoint 1, callee.increment (val=3Dval@entry=3D99.0, msg= =3D...) at callee.adb:19 Currently, since 2023-12-14 "gdb: make get_frame_register_bytes take the next frame" (9fc79b42369): > Temporary breakpoint 1, callee.increment (val=3D, val@en= try=3D0.0, msg=3D...) at callee.adb:19 Applying the attached patch gets us the expected output back, and does not introduce further regressions that I could find. I've tried it on top of both master and your recently submitted "register value cleanups" series, <20231221191716.257256-1-simon.marchi@efficios.com>. Let me know if I've missed something! > + unavailablep)) > return 0; >=20=20 > target_float_convert (from, builtin_type (gdbarch)->builtin_double, --=-=-= Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename=0001-gdb-fix-refactoring-hiccup-in-rs6000_register_to_val.patch Content-Transfer-Encoding: quoted-printable >From 0fae84368f22250cb672c467e56652103fbb8c49 Mon Sep 17 00:00:00 2001 From: =3D?UTF-8?q?K=3DC3=3DA9vin=3D20Le=3D20Gouguec?=3D Date: Fri, 22 Dec 2023 14:06:15 +0100 Subject: [PATCH] gdb: fix refactoring hiccup in rs6000_register_to_value MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit In 2023-12-14 "gdb: make get_frame_register_bytes take the next frame" (9fc79b42369), *_register_to_value functions were made to (a) call get_next_frame_sentinel_okay (frame) (b) pass that next frame to get_frame_register_bytes. Step (b) was omitted for rs6000-tdep.c; this manifests as a regression on PPC platforms for e.g. O2_float_param: instead of seeing=E2=80=A6 Temporary breakpoint 1, callee.increment (val=3Dval@entry=3D99.0, msg=3D.= ..) at callee.adb:19 =E2=80=A6 we get "optimized_out" for val. Passing next_frame to get_frame_register_bytes fixes the issue. --- gdb/rs6000-tdep.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdb/rs6000-tdep.c b/gdb/rs6000-tdep.c index 1c9bb3e5f04..f043be08355 100644 --- a/gdb/rs6000-tdep.c +++ b/gdb/rs6000-tdep.c @@ -2716,7 +2716,7 @@ rs6000_register_to_value (frame_info_ptr frame, auto from_view =3D gdb::make_array_view (from, register_size (gdbarch, regnum)); frame_info_ptr next_frame =3D get_next_frame_sentinel_okay (frame); - if (!get_frame_register_bytes (frame, regnum, 0, from_view, optimizedp, + if (!get_frame_register_bytes (next_frame, regnum, 0, from_view, optimiz= edp, unavailablep)) return 0; =20 --=20 2.34.1 --=-=-=--