From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23024 invoked by alias); 2 Jul 2018 16:14:15 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 22975 invoked by uid 89); 2 Jul 2018 16:14:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.4 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=Doesnt, Doesn't, stronger, Hx-languages-length:1522 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-Spam-User: qpsmtpd, 3 recipients X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 02 Jul 2018 16:14:14 +0000 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id EB967AED7; Mon, 2 Jul 2018 16:14:11 +0000 (UTC) Date: Mon, 01 Jan 2018 00:00:00 -0000 From: Michael Matz To: Jakub Jelinek cc: Jeff Law , Florian Weimer , GCC , GNU C Library , Binutils , gnu-gabi@sourceware.org Subject: Re: Invalid program counters and unwinding In-Reply-To: <20180702155448.GW7166@tucnak> Message-ID: References: <6feeaf09-0bc2-238b-42df-2ff915f3581e@redhat.com> <2b47dbd9-f1a2-1bf0-06ca-fca40660fabf@redhat.com> <6c555c05-e6d7-f37a-577f-4e0559c36f76@redhat.com> <20180702155448.GW7166@tucnak> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-IsSubscribed: yes X-SW-Source: 2018-q3/txt/msg00002.txt.bz2 Hi, On Mon, 2 Jul 2018, Jakub Jelinek wrote: > > I disagree. ASM code often lacks unwind descriptors (now less than in > > the past, but still). My rule of thumb is always: no descriptor -> > > has to be a framepointer-using routine with standard calling sequence. > > (I.e. declare the combination of no descriptor and no fp to be a bug). > > Some of the callee-saved register will temporarily be wrong but > > unwinding can continue. > > Doesn't that clash with the x86-64 ABI which says what kind of FDE use > by default if none is found (essentially a standard leaf routine that > doesn't change sp, nor save any registers)? There is no such language in the psABI, no (at least I haven't found anything; you had me worried for a moment :) ). But there's stronger one: all functions through which unwinding is expected must provide CFI. So, yes, such code isn't strictly conforming. But there we are, there's much code that isn't and we still have to sensibly deal with it (if we can). IMHO making guesses is better than to stop unwinding. And IMHO guessing that it's FP-using is better than guessing that it's leaf, especially if the PC in question was the result of a prior unwinding step (making it clear that it certainly was _not_ leaf). And then there are (toy?) compilers that don't emit CFI, but do use FPs (totally psABI non-compliant, sure); IMHO we shouldn't pessimize them unduly. Yeah, it's all a bit wonky, but why make it harder for those? Ciao, Michael.