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 confor
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 comb
On Mon, Jul 02, 2018 at 05:48:32PM +0200, Michael Matz wrote:
> Hi,
>
> On Thu, 28 Jun 2018, Jeff Law wrote:
>
> > I believe "dumb" is referring to the fact that we're already in a bit of
> > a weird state as evidenced by the NULL FDE. Blindly trying to read the
> > contents of the PC that we
Hi,
On Thu, 28 Jun 2018, Jeff Law wrote:
> I believe "dumb" is referring to the fact that we're already in a bit of
> a weird state as evidenced by the NULL FDE. Blindly trying to read the
> contents of the PC that we couldn't map to an FDE is, IMHO, dumb.
>
> One might even be able to argue
On 06/28/2018 04:18 PM, Jeff Law wrote:
On 06/28/2018 06:30 AM, Florian Weimer wrote:
On 06/28/2018 04:16 AM, Jeff Law wrote:
Previous discussions:
https://gcc.gnu.org/ml/gcc/2013-05/msg00253.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
https://sourceware.org/ml/libc-alpha/2016-07/m
On 06/28/2018 06:30 AM, Florian Weimer wrote:
> On 06/28/2018 04:16 AM, Jeff Law wrote:
>>> Previous discussions:
>>>
>>> https://gcc.gnu.org/ml/gcc/2013-05/msg00253.html
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
>>> https://sourceware.org/ml/libc-alpha/2016-07/msg00613.html
>>> (pa
On 06/28/2018 04:16 AM, Jeff Law wrote:
Previous discussions:
https://gcc.gnu.org/ml/gcc/2013-05/msg00253.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
https://sourceware.org/ml/libc-alpha/2016-07/msg00613.html
(patch with a spread lock, still not async-signal-safe)
You might als
On 06/26/2018 03:26 AM, Florian Weimer wrote:
> I'm looking at ways to speed up _Unwind_Find_FDE when libgcc is running
> on top of glibc. I have something (at the design level, with some of
> the code written) which allows me to get a pointer to the
> PT_GNU_EH_FRAME segment in memory in a lock-f
On 06/26/2018 07:39 AM, Florian Weimer wrote:
On 06/26/2018 01:35 PM, Nathan Sidwell wrote:
IIRC, in gcc-land you have to give both noreturn and nothrow
attributes to make it non-unwindable.
Are you sure? I was under the impression that GCC did not do this
because it interferes too much wi
On Tue, Jun 26, 2018 at 01:39:18PM +0200, Florian Weimer wrote:
> > The @code{noreturn} keyword does not affect the exceptional path
> > when that applies: a @code{noreturn}-marked function may still
> > return to the caller by throwing an exception or calling
> > @code{longjmp}.
> >
> > IIRC, in
On 06/26/2018 01:35 PM, Nathan Sidwell wrote:
On 06/26/2018 07:21 AM, Florian Weimer wrote:
GCC doesn't do this AFAIK, but it's theoretically possible not to
preserve the return address for a noreturn function. But that would
be very bad for exception handling, so let's hope compilers don't d
On 06/26/2018 07:21 AM, Florian Weimer wrote:
GCC doesn't do this AFAIK, but it's theoretically possible not to
preserve the return address for a noreturn function. But that would be
very bad for exception handling, so let's hope compilers don't do this.
I'd forgotten about noreturn. Such f
On 06/26/2018 01:25 PM, Jakub Jelinek wrote:
On Tue, Jun 26, 2018 at 01:01:06PM +0200, Florian Weimer wrote:
On 06/26/2018 12:56 PM, Nathan Sidwell wrote:
On 06/26/2018 05:26 AM, Florian Weimer wrote:
So it looks to me that the caller of _Unwind_Find_FDE needs to
ensure that the PC is a valid
On Tue, Jun 26, 2018 at 01:01:06PM +0200, Florian Weimer wrote:
> On 06/26/2018 12:56 PM, Nathan Sidwell wrote:
> > On 06/26/2018 05:26 AM, Florian Weimer wrote:
> >
> > > So it looks to me that the caller of _Unwind_Find_FDE needs to
> > > ensure that the PC is a valid element of the call stack.
On 06/26/2018 01:15 PM, Nathan Sidwell wrote:
On 06/26/2018 07:01 AM, Florian Weimer wrote:
On 06/26/2018 12:56 PM, Nathan Sidwell wrote:
On 06/26/2018 05:26 AM, Florian Weimer wrote:
So it looks to me that the caller of _Unwind_Find_FDE needs to
ensure that the PC is a valid element of the c
On 06/26/2018 07:01 AM, Florian Weimer wrote:
On 06/26/2018 12:56 PM, Nathan Sidwell wrote:
On 06/26/2018 05:26 AM, Florian Weimer wrote:
So it looks to me that the caller of _Unwind_Find_FDE needs to ensure
that the PC is a valid element of the call stack. Is this a correct
assumption?
I
On 06/26/2018 12:56 PM, Nathan Sidwell wrote:
On 06/26/2018 05:26 AM, Florian Weimer wrote:
So it looks to me that the caller of _Unwind_Find_FDE needs to ensure
that the PC is a valid element of the call stack. Is this a correct
assumption?
I thought this was an (implicit?) requirement. Yo
On 06/26/2018 05:26 AM, Florian Weimer wrote:
So it looks to me that the caller of _Unwind_Find_FDE needs to ensure
that the PC is a valid element of the call stack. Is this a correct
assumption?
I thought this was an (implicit?) requirement. You're unwinding a stack
to deliver an exception
I'm looking at ways to speed up _Unwind_Find_FDE when libgcc is running
on top of glibc. I have something (at the design level, with some of
the code written) which allows me to get a pointer to the
PT_GNU_EH_FRAME segment in memory in a lock-free fashion (so it would
also be async-signal safe
19 matches
Mail list logo
