From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by sourceware.org (Postfix) with ESMTPS id 974C63888816 for ; Mon, 13 Feb 2023 14:24:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 974C63888816 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id D0E131F37E; Mon, 13 Feb 2023 14:24:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1676298298; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Y+OvQX2ubbCI9xWWWerGnzUh/cLKgj+zeItEFrsZx7I=; b=jna/cPy/KZKjPri7El133yyJx6qjyrbSYVkJmpgy4IakvE+HR7lB7cxl43kO2FcltGL38w po5usDEZqSEryLNV9Hr5gq9xJ4NA9BeNSZ5P2HGYMUd9CKUsgRGsUwJjpc5tEfApmQjzK4 u5jIMG1fyqMsGdxnlE1MB9vZwWcK9k4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1676298298; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Y+OvQX2ubbCI9xWWWerGnzUh/cLKgj+zeItEFrsZx7I=; b=U9pZRfWsw+AtUGZvzAaXvqAPr8qARYsgetVCwARaeRwgAf+sT6R9PT8OCrjc8YF2WScZ9+ cL+aRnqiy9II3EAw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id BBA62138E6; Mon, 13 Feb 2023 14:24:58 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id VkKnLDpI6mOnfwAAMHmgww (envelope-from ); Mon, 13 Feb 2023 14:24:58 +0000 Message-ID: Date: Mon, 13 Feb 2023 15:24:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH] [gdb/tdep] Assume epilogue unwind info is valid unless gcc < 4.5.0 To: Tom Tromey , Tom de Vries via Gdb-patches References: <20230121074807.22032-1-tdevries@suse.de> <87a62blqxn.fsf@tromey.com> <5d5eeb5d-bc39-c01f-53e8-d961ed0b98ea@suse.de> Content-Language: en-US From: Tom de Vries In-Reply-To: <5d5eeb5d-bc39-c01f-53e8-d961ed0b98ea@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP 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: On 1/27/23 22:13, Tom de Vries via Gdb-patches wrote: > On 1/21/23 18:48, Tom Tromey wrote: >>>>>>> "Tom" == Tom de Vries via Gdb-patches >>>>>>> writes: >> >> Tom> Fix these two issues by reversing the burden of proof: >> Tom> - currently we assume epilogue unwind info is invalid unless we >> can proof that >> Tom>   gcc >= 4.5.0. >> Tom> - instead, assume epilogue unwind info is valid unless we can >> proof that >> Tom>   gcc < 4.5.0. >> >> FWIW this approach makes sense to me. >> > > OK, then changing RFC -> PATCH. > >> It's pretty lame that there's no way to detect this failure from the >> frame section -- it can't be producer-sniffed and the augmentation >> strings can't really be changed. >> >> gcc 4.5 was released in 2010, and so it's not like we're inconveniencing >> a lot of users.  If needed I guess we could add a user setting to switch >> this behavior back on. >> >> Note there is a similar issue for the prologue, see: >> >> https://sourceware.org/bugzilla/show_bug.cgi?id=25696 >> https://sourceware.org/bugzilla/show_bug.cgi?id=17265 >> https://sourceware.org/bugzilla/show_bug.cgi?id=21470 >> >> Also worth seeing the hilarious: >> >> https://github.com/rust-lang/rust/issues/41252#issuecomment-293676579 >> >> I think that in this area we should assume the debug info is correct, >> and keep a list of known-bad producers rather than assuming the debug >> info is wrong and having a list of known-good ones. >> >> Tom> +  if (/* In absence of producer information, optimistically >> assume that we're >> Tom> +     not dealing with gcc < 4.5.0.  */ >> >> This placement of the comment is pretty weird, it seems fine to just >> stick it before the 'if'. >> > > Done. > >> Tom> +      if (cu->producer == nullptr) >> Tom> +    /* In absence of producer information, optimistically assume >> that we're >> Tom> +       not dealing with gcc < 4.5.0.  */ >> Tom> +    cust->set_epilogue_unwind_valid (true); >> Tom> +      if (!producer_is_gcc (cu->producer, nullptr, nullptr)) >> >> Normally if there is a comment and a line of code as the consequence of >> an 'if', we put them both in a block. >> > > Done. > >> Anyway I was also thinking that the second one should say 'else if'. > > True, thanks for catching that, also done. > > I've also added a test-case, for the amd64-tdep.c change. I could make > another one for the i386-tdep.c change, and/or one for the dwarf/read.c > change, but I'm not sure that's worth the trouble. > Posted v2 here: https://sourceware.org/pipermail/gdb-patches/2023-February/197011.html Thanks, - Tom