This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: v8.S dwarf2 eh frame issues again :(


On Sat, Apr 20, 2002 at 06:32:26PM -0700, David S. Miller wrote:
>    From: Richard Smith <richard@ex-parrot.com>
>    Date: Sat, 20 Apr 2002 16:28:09 +0100 (BST)
> 
>    On Sat, 20 Apr 2002 09:08:39 +0200, Jakub Jelinek wrote:
>    > On Fri, Apr 19, 2002 at 07:23:57PM -0700, David S. Miller wrote:
>    > >
>    > > Dwarf2 unwinds from libjava/testsuite/libjava.lang/invokethrow.java
>    > > fail to work unless I make the change at the end of thie email to the
>    > > .eh_frame information added recently to libffi/src/sparc/v8.S
>    
>    I've been tracking down a similar problems with C++ exceptions over the
>    last few days.  With any luck it's the same problem.
>    
> Based upon what I recall during my debugging sessions, I believe
> it is in fact the same problem.

Unfortunately not.
>From what I can see, ffi_call_V8 is the last function in libgcj.so having
frame information. In .eh_frame_hdr section, ffi_call's FDE is the last one
in the table though:

.eh_frame_hdr:
 46c388 011b033b 000d7840 000021ad ffb93c78  ...;..x@..!...<x
 46c398 00112eb4 ffdf7400 000d7860 ffdf7428  ......t...x..t(
...
 47d0e8 00112e4c fff8dc54 00112e68 fff8dd18  ...L...T...h....
 47d0f8 00112e84                             ....

0xffb93c78 + 0x46c388 = 0x0		, 0x112eb4 + 0x46c388 = 0x57f23c
0xfff8dd18 + 0x46c388 = 0x3fa0a0	, 0x112e84 + 0x46c388 = 0x57f20c

and in .eh_frame the end looks like:
 57f20c 00000018 000016c8 ffe7ae8c 0000009c  ................
 57f21c 00040000 00040d1e 2d090f1f 00000010  ........-.......
 57f22c 00000000 017a5200 017c0f01 500c0e00  .....zR..|..P...
 57f23c 00000018 00000018 00000000 00000094  ................
 57f24c 00040000 00040d1e 2d090f1f 00000000  ........-.......

57f20c-57f227 looks like proper ffi_call's FDE, then follows
a CIE from 57f228-57f23b (note DW_EH_PE_aligned (= 0x50) FDE
encoding, then followed supposedly by ffi_call_V8's which has
FDE initial location set to 0 not ffi_call_V8 though.
This matches what happens in .eh_frame_hdr.
Now to find out why the FDE initial loc in ffi_call_V8 gets cleared...
(will do once I return home tonight).

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]