--- Comment #32 from ebotcazou at gcc dot gnu dot org 2008-07-07 08:33
---
Jakub, the patch contains a workaround for the missing S in the CIE
augmentation
string for old kernels on PPC. Is this problem really specific to PPC? It
seems that I'm seeing it on x86 too with 2.6.8 and
--- Comment #31 from pluto at agmk dot net 2006-09-05 14:31 ---
is it possible to make gcc unwinder work for solaris too?
at this moment unwinding (after throwing the std::exception
from signal handler) on sunos-5.9 looks like this:
0x1141c : signalHandler(int)+0x8
--- Comment #30 from jakub at gcc dot gnu dot org 2006-04-06 13:30 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from jakub at gcc dot gnu dot org 2006-02-28 22:20 ---
Subject: Bug 26208
Author: jakub
Date: Tue Feb 28 22:20:34 2006
New Revision: 111581
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111581
Log:
PR other/26208
* unwind-dw2.c (struct
--- Comment #28 from jakub at gcc dot gnu dot org 2006-02-27 17:26 ---
Subject: Bug 26208
Author: jakub
Date: Mon Feb 27 17:26:26 2006
New Revision: 111488
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111488
Log:
PR other/26208
* unwind-dw2.c (struct
--- Comment #27 from jakub at gcc dot gnu dot org 2006-02-26 22:16 ---
Created an attachment (id=10915)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10915action=view)
gcc-trunk-pr26208-2.patch
Incremental patch that introduces _Unwind_GetIPInfo (if anyone knows better
name,
--- Comment #23 from jakub at gcc dot gnu dot org 2006-02-24 19:45 ---
Created an attachment (id=10909)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10909action=view)
gcc-trunk-pr26208.patch
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #24 from jakub at gcc dot gnu dot org 2006-02-24 19:45 ---
Created an attachment (id=10910)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10910action=view)
binutils-trunk-pr26208.patch
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #25 from jakub at gcc dot gnu dot org 2006-02-24 19:56 ---
Updated patches. Unfortunately, it seems even this is not enough as Java
(and C++ as well, but there we aren't expecting to throw through signal
frames), the personality routine does the same as uw_frame_state_for
--- Comment #26 from rth at gcc dot gnu dot org 2006-02-25 01:00 ---
I agree we shouldn't mess with _Unwind_GetIP. While I kinda like the idea
behind _Unwind_SignalFrameContext, I'm not sure I like the idea of the
effectively mandatory back-to-back PLT calls. If you think that _U_SFC
--- Comment #17 from jakub at gcc dot gnu dot org 2006-02-22 08:11 ---
The nop before the signal trampoline is needed for similar reason, but one
signal frame lower. A normal signal frame lower in the stack will contain
the exact address of the start of the trampoline (or in unusual
--- Comment #18 from uweigand at gcc dot gnu dot org 2006-02-22 09:57
---
(In reply to comment #17)
(e.g. s390/linux-unwind.h was doing that, although just for 2 selected
signals, which wasn't good enough, as e.g. all async signals need to be
handled the same).
We've actually
--- Comment #19 from jakub at gcc dot gnu dot org 2006-02-22 10:25 ---
Sure, if you want to do that for s390, s390/linux-unwind.h can still do
if (!signo || (*signo != 4 *signo != 5 *signo != 8))
fs-signal_frame = 1;
(I think !signo - fs-signal_frame = 1; is better default, there
--- Comment #20 from amodra at bigpond dot net dot au 2006-02-23 00:41
---
Created an attachment (id=10895)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10895action=view)
updated for powerpc and powerpc64
Jakub of course is correct that the vdso eh_frame dwarf2 can't increment
--- Comment #21 from rth at gcc dot gnu dot org 2006-02-23 01:01 ---
No. MFUC only applies when there is no unwind information available. When
the vdso is present, unwind information is available.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
--- Comment #22 from amodra at bigpond dot net dot au 2006-02-23 01:08
---
Richard, aren't you confusing MD_FALLBACK_FRAME_STATE_FOR with
MD_FROB_UPDATE_CONTEXT? The former only happens when we have no unwind, the
latter on each uw_update_context.
--
--- Comment #6 from jakub at gcc dot gnu dot org 2006-02-21 12:02 ---
Created an attachment (id=10884)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10884action=view)
gcc-trunk-pr26208.patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
--- Comment #7 from jakub at gcc dot gnu dot org 2006-02-21 12:02 ---
Created an attachment (id=10885)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10885action=view)
binutils-trunk-pr26208.patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
--- Comment #8 from jakub at gcc dot gnu dot org 2006-02-21 13:12 ---
Created an attachment (id=10886)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10886action=view)
linux-2.6.15-pr26208.patch
This is what I have so far (libjava not done yet), but I'm not sure a simple
CIE flag
--- Comment #9 from jakub at gcc dot gnu dot org 2006-02-21 17:52 ---
This is related to the almost forgotten
http://sources.redhat.com/bugzilla/show_bug.cgi?id=300
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
--- Comment #10 from rth at gcc dot gnu dot org 2006-02-21 18:47 ---
(In reply to comment #8)
This is what I have so far (libjava not done yet)
The patches so far look fine.
but I'm not sure a simple CIE flag isn't sufficient on all arches.
You're confounding two different
--- Comment #11 from jakub at gcc dot gnu dot org 2006-02-21 22:09 ---
Treating all signal frames as _Unwind_Find_FDE (context-ra, ...) and
fs-pc = context-ra is certainly better than what we are doing now, but
it will only work say on s390 (other arches that raise exception after
the
--- Comment #12 from rth at gcc dot gnu dot org 2006-02-21 23:09 ---
Since no one *currently* cares about unwinding from SIGFPE (how could they,
since it doesn't work on the most popular platform), I think we should ignore
this issue entirely.
The Fix is to ensure that, on a
--- Comment #13 from jakub at gcc dot gnu dot org 2006-02-21 23:15 ---
Ok, let's S be unconditional CIE flag without any CFA expression and if
a real need for CFA expression ever arises, we can always add another flag,
right?
If so, I'll work on finishing the libjava bits and start
--- Comment #14 from rth at gcc dot gnu dot org 2006-02-21 23:25 ---
I guess a .cfi_signal_frame directive would be nice, but not strictly required.
Ideally one should never have to write .eh_frame by hand.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
--- Comment #15 from amodra at bigpond dot net dot au 2006-02-22 01:13
---
ppc vdso caters for pc-1 with the following.
/* The nop here is a hack. The dwarf2 unwind routines subtract 1 from
the return address to get an address in the middle of the presumed
call instruction.
--- Comment #16 from amodra at bigpond dot net dot au 2006-02-22 05:11
---
In regard to comment #15, I see that is only half the problem. The real
difficulty is in the last sentence of Jakub's report. Hmm. I suppose we could
make the ppc vdso eh_frame info adjust the pc as
--- Comment #1 from jakub at gcc dot gnu dot org 2006-02-10 08:23 ---
Created an attachment (id=10814)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10814action=view)
cleanup-12.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
--- Comment #2 from jakub at gcc dot gnu dot org 2006-02-10 08:23 ---
Created an attachment (id=10815)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10815action=view)
cleanup-12a.S
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #3 from uweigand at gcc dot gnu dot org 2006-02-10 20:00
---
Yup. See how this is handled in config/s390/linux-unwind.c:
/* If we got a SIGSEGV or a SIGBUS, the PSW address points *to*
the faulting instruction, not after it. This causes the logic
in
--- Comment #4 from jakub at gcc dot gnu dot org 2006-02-10 20:18 ---
Not all the targets have the luxury of spare register slots.
So the current proposal is to add a new CIE augmentation that will signify
a signal frame.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
--- Comment #5 from uweigand at gcc dot gnu dot org 2006-02-10 20:34
---
(In reply to comment #4)
Not all the targets have the luxury of spare register slots.
I guess we were lucky here ;-)
So the current proposal is to add a new CIE augmentation that will signify
a signal frame.
33 matches
Mail list logo
