From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id HsE+As57iWgypz8AWB0awg (envelope-from ) for ; Tue, 29 Jul 2025 21:56:30 -0400 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=hgXqjLNT; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id EB4131E102; Tue, 29 Jul 2025 21:56:29 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.8 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_SBL_CSS,RCVD_IN_VALIDITY_CERTIFIED, RCVD_IN_VALIDITY_RPBL,RCVD_IN_VALIDITY_SAFE autolearn=ham autolearn_force=no version=4.0.1 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 ED67F1E089 for ; Tue, 29 Jul 2025 21:56:28 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 753843858D32 for ; Wed, 30 Jul 2025 01:56:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 753843858D32 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=hgXqjLNT Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) by sourceware.org (Postfix) with ESMTPS id B43F73858D26 for ; Wed, 30 Jul 2025 01:55:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B43F73858D26 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 B43F73858D26 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::431 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1753840513; cv=none; b=pGlh85iyH7PPhOi9CZ8FBKGxEr4+0VeIRWZ1VjR1awXD83zzQ2vEghDlXyu4h2PJHBtToNa5LZUlds3q7/AGSXRxMhBhsaOaoCwq7k5Dg/usBLqSPfTcf/LA1n/dkSDULQGFmvs/b+wWzZg8QmcfBph86FulZOg6XrKbs/rMOcg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1753840513; c=relaxed/simple; bh=WZ6+hH5r9eK7ry0AP4BNakTsvkEoryOt1lbnMijrZOw=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=n1QMD0SPTnvxdwiuRQPmllbWQbBtaL/zJm8eEKtx6a5FYCghyNrSIB1GbFUaufmt7CX7fraCcOUPslIF/aiui1ggiQHqQZ5H59va5ZLDA6oiYWCjZFeLjL55Gi9+REqkmOoYoGSzlBcGGSb/X7N7s4xjZ00TVpudjaMoAtaaVjU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B43F73858D26 Received: by mail-pf1-x431.google.com with SMTP id d2e1a72fcca58-748e81d37a7so4183068b3a.1 for ; Tue, 29 Jul 2025 18:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1753840513; x=1754445313; 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=d3sQI1fklB8bYhr3ORrbKJb284QJOvOgFB4s1o6sKGg=; b=hgXqjLNTAcJz5W0mB5n/899lrFMEj73bW9RDDpSJf2TvXWJMDzSJMDc5npbdGR5GPD hlf9mix/3g7Pq1QiCIhCJ5SkG8TbBplmXYfis0aSHbxHBHEs42XxTL3sBghPsSfECJ9k 4e7qs1UEcMIPHh+UwSeYFKzNY/6d8o5jTCGKSWMwIxCbMOFmPQEPb8oSef2LdQpcigEv 2hP2OHQtRREkmbZZ/KdmBXcn7vTiEOYR6R0q7oSSMOcvgBQEboFLsjj+/KBRdZuBmF6g /pbZsHsx83tobamJERspbzoQxBAPZtdkQZzkqiVDd+0s9TpaRmDuiOUa/QIC41C8oXkj ehrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753840513; x=1754445313; 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=d3sQI1fklB8bYhr3ORrbKJb284QJOvOgFB4s1o6sKGg=; b=YMqd1ff5LME0hTTVzChwIElkEmYpj/TU27jVUuiwp+gwL7HkNZeLepWdH3Vl0g67iG sZSKsW5Axa82yTMi1DO3Zjv/PeiUPAan/HfI9EcYmRnTLLFNO20YX0N3NlrBu48Xu0gx HMQtHDpPZJWN2Ba5Ok5ThfGcH1a0kjI00qZ/XuMf2mfXLoaZf8n95F7P+VMT+647ExhZ Za5i2YZUb+EbNzkT3T9p8VTyjikzuvvnJWO3S8ezX8++WmN6ENyhEcW77rQA7xxsyg5S nYwL3xmMqT0/J6YNbgGzw66JtoIwdGwFdKjLVlt/wSd+B7YcvP7ODWxHkQqf0txMT2vg s14w== X-Forwarded-Encrypted: i=1; AJvYcCXXAru9MfoOqu7lFLBz4PBodrwa77PLdAOTeWc3LHedvjVfDBLWuc8p76HATnga7t7YWEorJSlp9ZfWyw==@sourceware.org X-Gm-Message-State: AOJu0YwCBFcwIx3jDy9vk8MOcXcKjVDuo1csIV3ZPweBz1GFq05JaqKU ao7gwnyV9QX3XNGNXKQhoAJ5CdPPCdud4QoeShd7j2/HtaE2MFmfG2wOr7sd+GA9vf8= X-Gm-Gg: ASbGncvwe9C0D2egin9Wpu5kIjHM6YtUFm8fqLQdPAyEGWt/c3RiUdNWyvvXhZXypqB cVDtxzrm6XwsUnKf12olqVkjplnLYhUcwZ2/XVyPLe6/QzrJsTLFY3KqHWBc+2Ki1bBKQwtn4Y3 GTLo78iawq3FdEiYUF3cWv9SvC8DhjbYyE+u1i+/corA18AhTptidQjmmLiQwAJgjBzm6ZEFRc+ x+RXYPidiw8ajt/CnFirWjzOvSPmSMpJ6YYIn9AmWo4in/VqA72tApaHjg2nguZDlFlli/d0vNf UW4R4+pVCyuY83GP1YhYdgVS8qw5BhROv5lWBIbCoO01lTKEQSGS+sZ0mo49dvPpKsRV0SzgCeD HmjQN9+MTRjJDFTDVbFOtjoUHZ9XYIzfk X-Google-Smtp-Source: AGHT+IHgKStSUl6Qh/uiS4TG1y9/HL/M9LjMjugiwN7UpLoEdvboq4PvTPZeWEr/i/SzFSQJwNgoFw== X-Received: by 2002:a05:6a00:2e0e:b0:749:4fd7:3513 with SMTP id d2e1a72fcca58-76ab3096e9dmr2016293b3a.16.1753840512559; Tue, 29 Jul 2025 18:55:12 -0700 (PDT) Received: from localhost ([2804:14d:7e39:88d6:f859:cd13:74ec:238c]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-76408cf75dfsm8582883b3a.50.2025.07.29.18.55.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Jul 2025 18:55:12 -0700 (PDT) From: Thiago Jung Bauermann To: Andrew Burgess Cc: Christina Schimpe , gdb-patches@sourceware.org, luis.machado@arm.com Subject: Re: [PATCH v5 07/12] gdb: amd64 linux coredump support with shadow stack. In-Reply-To: <87o6t3cawd.fsf@redhat.com> (Andrew Burgess's message of "Tue, 29 Jul 2025 15:46:42 +0100") References: <20250628082810.332526-1-christina.schimpe@intel.com> <20250628082810.332526-8-christina.schimpe@intel.com> <87o6t3cawd.fsf@redhat.com> User-Agent: mu4e 1.12.11; emacs 30.1 Date: Tue, 29 Jul 2025 22:55:10 -0300 Message-ID: <87tt2u788x.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 Andrew, Christina based the testcase in this patch on aarch64-gcs-core.exp from my GCS patch series and your comments on it also apply to my patch, so I'm replying on account of that. Andrew Burgess writes: > Christina Schimpe writes: > >> + # Generate the gcore core file. >> + set gcore_filename [standard_output_file "${testfile}.gcore"] >> + set gcore_generated [gdb_gcore_cmd "$gcore_filename" "generate gcore file"] >> + >> + # Obtain an OS-generated core file. Save test program output to >> + # ${binfile}.out. >> + set core_filename [core_find $binfile {} {} "${binfile}.out"] >> + set core_generated [expr {$core_filename != ""}] >> + set os_core_name "${binfile}.core" >> + remote_exec build "mv $core_filename $os_core_name" >> + set core_filename $os_core_name > > I'm wondering what the point of this core_filename / os_core_name stuff > is? My reading of `core_find` is that the returned core_filename will > be '${binfile}.core', so this whole thing feels redundant, but maybe I'm > missing something here? I wrote this part. The answer to your question is very simple: I don't know what I was thinking. I just deleted the last 3 lines from the GCS testcase. >> + >> + # At this point we have a couple of core files, the gcore one generated by >> + # GDB and the one generated by the operating system. Make sure GDB can >> + # read both correctly. >> + >> + if {$gcore_generated} { >> + clean_restart $binfile >> + >> + with_test_prefix "gcore corefile" { >> + check_core_file $gcore_filename $ssp_in_gcore >> + } >> + } else { >> + fail "gcore corefile not generated" > > It's better, where possible, to avoid having pass/fail results that only > show up down some code paths. > > In this case it's easy to avoid having a stray 'fail' by restructuring > the code too: > > gdb_assert { $gcore_generated } "gcore corefile created" > if { $gcore_generated } { > ... etc ... > } > > Now you'll always have either a pass or fail based on the gcore being > generated. Good idea. I did that for aarch64-gcs-core.exp. > There is also the helper proc `gcore_cmd_available`. I'd guess for any > x86 target that supports SSP, gcore will be available, but in theory you > could consider using this to avoid a fail when gcore is not available > maybe? In the GCS core testcase, I moved the gcore tests after the OS corefile ones, with an if ![gcore_cmd_available] { return } in the middle, and after that I had to redo some GDB setup: clean_restart $binfile if ![runto $linespec] { return } But I agree it does make it more resilient/correct. Thanks for the suggestion. >> + } >> + >> + if {$core_generated} { >> + clean_restart $binfile >> + >> + with_test_prefix "OS corefile" { >> + # Read ssp value from saved output of the test program. >> + set out_id [open ${binfile}.out "r"] >> + set ssp_in_gcore [gets $out_id] >> + >> + close $out_id >> + check_core_file $core_filename $ssp_in_gcore > > I'd move the blank line after the 'close' personally. I also had that layout. Changed. -- Thiago