public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
From: Michael Matz <matz@suse.de>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Jeff Law <law@redhat.com>, Florian Weimer <fweimer@redhat.com>,
	    GCC <gcc@gcc.gnu.org>,
	GNU C Library <libc-alpha@sourceware.org>,
	    Binutils <binutils@sourceware.org>,
	gnu-gabi@sourceware.org
Subject: Re: Invalid program counters and unwinding
Date: Mon, 01 Jan 2018 00:00:00 -0000	[thread overview]
Message-ID: <alpine.LSU.2.21.1807021803020.15410@wotan.suse.de> (raw)
In-Reply-To: <20180702155448.GW7166@tucnak>

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.

  reply	other threads:[~2018-07-02 16:14 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-01  0:00 Florian Weimer
2018-01-01  0:00 ` Jeff Law
2018-01-01  0:00   ` Florian Weimer
2018-01-01  0:00     ` Jeff Law
2018-01-01  0:00       ` Michael Matz
2018-01-01  0:00         ` Jakub Jelinek
2018-01-01  0:00           ` Michael Matz [this message]
2018-01-01  0:00             ` Florian Weimer
2018-01-01  0:00       ` Florian Weimer
2018-01-01  0:00 ` Nathan Sidwell
2018-01-01  0:00   ` Florian Weimer
2018-01-01  0:00     ` Jakub Jelinek
2018-01-01  0:00       ` Florian Weimer
2018-01-01  0:00     ` Nathan Sidwell
2018-01-01  0:00       ` Florian Weimer
2018-01-01  0:00         ` Nathan Sidwell
2018-01-01  0:00           ` Florian Weimer
2018-01-01  0:00             ` Nathan Sidwell
2018-01-01  0:00             ` Jakub Jelinek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LSU.2.21.1807021803020.15410@wotan.suse.de \
    --to=matz@suse.de \
    --cc=binutils@sourceware.org \
    --cc=fweimer@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=gnu-gabi@sourceware.org \
    --cc=jakub@redhat.com \
    --cc=law@redhat.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).