This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java 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] | |
Note that even then there are some situations (invocation API) where neither _Jv_RunMain or _Jv_ThreadStart will be on the stack.
...would you happen to know what *will* be there on the call stack in this case?
This part of the patch is a bit awkward - duplicating the interpreter-specific code is fragile and will make maintenance more difficult. Couldn't we instead have fallback_backtrace call the real UnwindTraceFn? I believe _Unwind_context is an opaque type, so it should be possible to have fallback_backtrace pass its own data there.
I sort of agree. However, if you look at the code there, it calls _Unwind_GetRegionStart() and _Unwind_GetIPInfo() - I'll have to #ifdef these out and somehow shoehorn the SJLJ EH equivalents in there since the default implementations of these functions provided by GCC for SJLJ EH are of no use to us.
Hmm. There shouldn't be any problems here (on Linux) - do you have a test case?
Yes. See: - ---------------------------- 8< ---------------------------- 1 public class Ex { 2 void snafu( ) throws Exception { 3 throw new Exception( "I do not like you!"); 4 } 5 void bar( ) throws Exception { 6 snafu( ); 7 } 8 void foo( ) throws Exception { 9 bar( ); 10 } 11 public static void main( String[] args) throws Exception { 12 new Ex( ).foo( ); 13 } 14 } - ---------------------------- 8< ----------------------------
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |