This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Invalid program counters and unwinding
- From: Florian Weimer <fweimer at redhat dot com>
- To: Michael Matz <matz at suse dot de>, Jakub Jelinek <jakub at redhat dot com>
- Cc: Jeff Law <law at redhat dot com>, GCC <gcc at gcc dot gnu dot org>, GNU C Library <libc-alpha at sourceware dot org>, Binutils <binutils at sourceware dot org>, gnu-gabi at sourceware dot org
- Date: Thu, 5 Jul 2018 21:31:19 +0200
- Subject: Re: Invalid program counters and unwinding
- References: <ae764484-5bd4-5e40-ed50-81209eb54360@redhat.com> <6feeaf09-0bc2-238b-42df-2ff915f3581e@redhat.com> <2b47dbd9-f1a2-1bf0-06ca-fca40660fabf@redhat.com> <6c555c05-e6d7-f37a-577f-4e0559c36f76@redhat.com> <alpine.LSU.2.21.1807021743390.15410@wotan.suse.de> <20180702155448.GW7166@tucnak> <alpine.LSU.2.21.1807021803020.15410@wotan.suse.de>
On 07/02/2018 06:14 PM, Michael Matz wrote:
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).
Well, the previous frame could have been a signal handler frame, but I
see your point.
Anyway, I've proposed a BoF for these topics for the next Cauldron.
Thanks,
Florian