From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id KNjvI2aSgmflvwoAWB0awg (envelope-from ) for ; Sat, 11 Jan 2025 10:46:46 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=V1L6+ZUL; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 8FA371E0C0; Sat, 11 Jan 2025 10:46:46 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.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 autolearn=unavailable autolearn_force=no version=4.0.0 Received: from server2.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 ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 207621E05C for ; Sat, 11 Jan 2025 10:46:46 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B6C77385840B for ; Sat, 11 Jan 2025 15:46:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B6C77385840B Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=V1L6+ZUL Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) by sourceware.org (Postfix) with ESMTPS id B174D3858D3C for ; Sat, 11 Jan 2025 15:46:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B174D3858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B174D3858D3C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::331 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1736610374; cv=none; b=e0bF0ZiF9p3EIIJCctmz0tQdyjVU9l/5h32EiGqU4J4neHL/5IbdNPk3ljfyMFO5Z7T2XEUQcLoZ1wlHboqYrYrnnKA69o3OwJQT0xUanzquXNoXbR634ezQhZ5s8HwBkmlvKHEspH9gCpj9IG/xxOscsoKovHSqSBiBk9Lx7Us= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1736610374; c=relaxed/simple; bh=gu4go26HC1Y9B2bEOiujisUY/D+5fgNXhCpv56860HI=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=ghj+8bEgCVWVDnoTTYOoBYmu+M4H87o43IFMlhXy7BdIMLRMbX4EUeYK0Qpi9vstXqIxo3nI0pyULsPl5qOUbf+1+rH1V83lIEfT/Bn27JR/M86JoyAHwfmKaCB0FfBkX6lsJluLvihdVLfvERdsWSHAXn0uC6cFuRwSoF1cv08= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B174D3858D3C Received: by mail-ot1-x331.google.com with SMTP id 46e09a7af769-71e1158fe3eso1598743a34.1 for ; Sat, 11 Jan 2025 07:46:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1736610374; x=1737215174; darn=sourceware.org; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=54ODTIt2viHapP8CAL5sDTsq0viI3SakP12bCJq4Els=; b=V1L6+ZUL433CJrnxNLY5nlRqw2c1TqeI9MWUkG7PkAogw2uwkhXQwlz/pnHeoBUDhC 2eHkFgyye06ynel7cZBgZCT0C9JFpN0pCsTpfoL7wdkie8/4SUt79v3KB6ti9M0ad0Hp zybB37TaOTFyyxmcxeAI49gxmaX2J0Tg7Rj4q6c6N2R7ic19C7BhVA1jQtFX7zt3JLOE In56JB89j2w25W8wx/8CHJX5W2oY3D+LfckGs2yh68lO/G99pN5N1t3qcojp1Se2/afS Dv9jIzmuQV78DtN+qmA6flvFwYBhAyXgleWuaYCC0meCgFEzhstxy2Ti7KyyAq8yyUoQ T1AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736610374; x=1737215174; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=54ODTIt2viHapP8CAL5sDTsq0viI3SakP12bCJq4Els=; b=AVn8Dio0q32CkAKbnk+U7YZLzOl30c+ZGBscZfEzaUSgF6O/s9v0vpcFqOiTP2oPG2 S61kOHbedpQObCjxz2sivH5zPUY/SP39xy/FXOPUxshvz2MxyDQ/getDEhRZFlqxcETM kNrLJsfXv470zmQwxE9MHrj7ctF/ztAxbZVymMOHKb4D2PzM4mSYDbyMgodiBLnHQ3Lm /ZVJrIB4p8CADJL0LJn+8Fr7Znky1ts5GwZ0YXPiHh4oE0M+Kuhbx9Kj0Q3D2bZgCGl1 kiGnBEkgiNf0Kugro1DCMWYlg/DsL/q/Q7vqOrBoEGmFAMDwGprYrKE44c1clJZm9IaG Obtw== X-Forwarded-Encrypted: i=1; AJvYcCUgFsDvHY+IGX45QX3m4UrbSeO4KeYTqcmKk8EIlw6KNg13pAXSxU4ByoR2qm/quRgcisYMSZMjmu7/1Q==@sourceware.org X-Gm-Message-State: AOJu0YzgGE1Fslq6raJFn+yAsoZk/EenCjT4VstCpLkeglYP7QRwsx6t 3V9T3w6C9igQJZ+jBP6tURnjWnz1m8/n+GGboGG4YcSjpY3LOL0vI2gZFO7RiXQ= X-Gm-Gg: ASbGnctN8HzVtKFHxS5oRYkt73KF7S0TKJ+R1uy0x65OL8BFQvdxaeU3C8srxibksDo KjlFD7nWTSeHBVUvOMlp9xdGw8VD6/nl7iNzxHedVejOZRzHKx0rL6LFK6Zx+UT8ijgcCzUhqED rq79btHYwEU0pJNc4l/i3JIuIyKmY7cPEFa4i8g+rRp4Rt2U8lnySpAHN9YSTN/VbCL18wcy1Z3 DjNCi0zeqr9cgob1DEiagIdV+/MjN2W1yxr1hvZrCs4tcATggpb8kR/52IqdMol/7o= X-Google-Smtp-Source: AGHT+IHf7h+/ArZfd/UuP0HYzIu18XzX5GSMVGSjgtRwvis1ORVnN+AWiizRbB9scnWgfLv4/4BXxg== X-Received: by 2002:a05:6830:6c8e:b0:71e:2881:54c6 with SMTP id 46e09a7af769-721e2ec21a2mr7128675a34.27.1736610373925; Sat, 11 Jan 2025 07:46:13 -0800 (PST) Received: from localhost ([2804:14d:7e39:8470:7cc9:6f0a:1353:265b]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7231855fd71sm1738514a34.42.2025.01.11.07.46.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Jan 2025 07:46:13 -0800 (PST) From: Thiago Jung Bauermann To: Tom de Vries Cc: Simon Marchi , gdb-patches@sourceware.org, "Aktemur, Tankut Baris" , "Maciej W. Rozycki" Subject: Re: [PATCH 2/2] GDB: Use gdb::array_view for buffers used in register reading and unwinding In-Reply-To: <347ca2f6-aa4a-4f08-8675-a8f0bce65e93@suse.de> (Tom de Vries's message of "Sat, 11 Jan 2025 14:54:40 +0100") References: <20250110164430.3376697-1-thiago.bauermann@linaro.org> <20250110164430.3376697-3-thiago.bauermann@linaro.org> <321e71e0-43de-4604-bb7e-34f6f64b83bf@simark.ca> <871pxa9udr.fsf@linaro.org> <347ca2f6-aa4a-4f08-8675-a8f0bce65e93@suse.de> User-Agent: mu4e 1.12.8; emacs 29.4 Date: Sat, 11 Jan 2025 12:46:09 -0300 Message-ID: <87ikql8ibi.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain 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 Hello Tom, Tom de Vries writes: > On 1/10/25 23:28, Thiago Jung Bauermann wrote: >> + gdb_assert (buffer.size () >= value->type ()->length ()); >> + > > This causes a regression on s390x-linux for test-case gdb.base/return.exp: > ... > (gdb) PASS: gdb.base/return.exp: continue to return of -5 > return 5^M > Make func2 return now? (y or n) y^M > /home/vries/gdb/src/gdb/frame.c:1207: internal-error: frame_register_unwind: Assertion > `buffer.size () >= value->type ()->length ()' failed.^M > A problem internal to GDB has been detected,^M > further debugging may prove unreliable.^M > ----- Backtrace -----^M > FAIL: gdb.base/return.exp: return value 5 (GDB internal error) > ... > > Before the commit, the test-case produces a fail, but doesn't assert: > ... > (gdb) PASS: gdb.base/return.exp: continue to return of -5 > return 5^M > Make func2 return now? (y or n) y^M > value has been optimized out^M > (gdb) FAIL: gdb.base/return.exp: return value 5 > ... > > Concretely, we're trying to read machine register r11, which according to the CFI is saved > in dwarf register 16: > ... > DW_CFA_register: r11 in r16 (f0) > ... > > Dwarf register 16 corresponds to f0 / v0 according to the ABI, and since v0 is available, > v0 is picked by s390_dwarf_reg_to_regnum. > > The assert then fails because the buffer that should hold the value of 8 byte register > r11: > ... > (gdb) p buffer.size () > $1 = 8 > ... > is smaller than the size of register v0: > ... > (gdb) p value->type ()->length () > $2 = 16 > ... > > Removing the assert reverts back to previous behaviour. Thank you for debugging the issue! So memcpy was overflowing the buffer. Nice to see the assert in action. :) > Properly fixing this requires us to only look at the part that is relevant, copying the > value from there, and checking for optimized out and unavailable only there. > > This worked for s390x-linux: > ... > diff --git a/gdb/frame.c b/gdb/frame.c > index 10a32dcd896..02583857019 100644 > --- a/gdb/frame.c > +++ b/gdb/frame.c > @@ -1193,8 +1193,14 @@ frame_register_unwind (const frame_info_ptr &next_frame, int > regnum, > > gdb_assert (value != NULL); > > - *optimizedp = value->optimized_out (); > - *unavailablep = !value->entirely_available (); > + if (value->lazy ()) > + value->fetch_lazy (); > + > + *optimizedp > + = value->bits_any_optimized_out (value->offset () * 8, > + buffer.size () * 8); > + *unavailablep > + = !value->bytes_available (value->offset (), buffer.size ()); > *lvalp = value->lval (); > *addrp = value->address (); > if (*lvalp == lval_register) > @@ -1204,13 +1210,17 @@ frame_register_unwind (const frame_info_ptr &next_frame, int > regnum, > > if (!buffer.empty ()) > { > - gdb_assert (buffer.size () >= value->type ()->length ()); > + gdb_assert (buffer.size () > + <= value->type ()->length () - value->offset ()); It should be '>=' above. > if (!*optimizedp && !*unavailablep) > - memcpy (buffer.data (), value->contents_all ().data (), > - value->type ()->length ()); > + { > + auto value_part > + = value->contents_all ().slice (value->offset (), buffer.size ()); > + memcpy (buffer.data (), value_part.data (), buffer.size ()); > + } > else > - memset (buffer.data (), 0, value->type ()->length ()); > + memset (buffer.data (), 0, buffer.size ()); > } > > /* Dispose of the new value. This prevents watchpoints from > ... Thank you for the patch! With the fix in the assert comparison: Reviewed-by: Thiago Jung Bauermann -- Thiago