This is the mail archive of the java-prs@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]

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9



------- Comment #47 from howarth at nitro dot med dot uc dot edu  2010-08-11 13:42 -------
Also from a the darwin unwinder maintainer...

> I  took a look at the bug report you made.   Right off, I can tell that  
> the problem is that _Unwind_FindEnclosingFunction() is not  
> implemented.  Well, it is implemented as a not_implemented macro...   
> It is an FSF extension and has some semantics that can't be supported.
...
> _Unwind_Find_FDE is implemented on 10.6.
> 
> The general issue is that on 10.6 and later the dwarf unwind info may  
> not exist.  It may be replaced (by the linker tool) with compact  
> unwind info.  So any function that assumes FDEs exist may not work.

This is the reason that the  _Unwind_FindEnclosingFunction() call is
re-exported
under a different name in libgcc_ext. This call requires _Unwind_Find_FDE and
has been replaced with a not_implemented macro which silently aborts. A radar
is open to have the gross use of not_implemented macros replaced with a check
if -no-compact-unwind is in use. In that case, the compatibility unwinder in
libSystem (which supports FDEs) would be in use and those calls could be made
functional again.
    Note that this all stems from the fact that darwin10 has the compact unwind
code generation as the default. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991


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