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

Re: [patch] Fix oddity in personality routine


On Mon, Nov 16, 2009 at 04:58:10PM +0000, Andrew Haley wrote:
> Jack Howarth wrote:
> > On Mon, Nov 16, 2009@03:16:07PM +0000, Andrew Haley wrote:
> >> Jack Howarth wrote:
> >>>    I should also add that my results from testing the
> >>> various i386 and x86_64 fink gcc44 and gcc45 packages
> >>> under darwin9 and darwin10 are confusing. I find for
> >>> gcj compiling java (but not class) files...
> >>>
> >>>            i386-darwin9   x86_64-darwin9  i386-darwin10  x86_darwin10
> >>> gcc 4.4.2    works           aborts         aborts          aborts
> >>> gcc 4.5      aborts          aborts         aborts          aborts
> >>>
> >>> I have a backport of the darwin10 patches from gcc 4.4
> >>> that I can add to the current gcc 4.3 branch and try that
> >>> but my gut instinct is that@best we will only find some
> >>> revision where the latent problem is triggered but not
> >>> indicating the exact origin of the problem.
> >>>                Jack
> >>> ps It might still be a good first step to make the Makefiles
> >>> coherent (which they don't seem to be@the moment) with
> >>> regard to the ecjx linkage flags.
> >> The first step surely would be to have a look and see why ecj1 is
> >> aborting.
> 
> >    I'll double check with my patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c10
> > but originally ecj1 was failing as shown in the backtrace of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c1.
> 
> Here:
> 
>   /* If code == _URC_END_OF_STACK, then we reached top of stack without
>      finding a handler for the exception.  Since each thread is run in
>      a try/catch, this oughtn't happen.  If code is something else, we
>      encountered some sort of heinous lossage from which we could not
>      recover.  As is the way of such things, almost certainly we will have
>      crashed before now, rather than actually being able to diagnose the
>      problem.  */
>   abort();
> 
> In other words, the stack unwinder has failed.  I can't see any alternative
> to stepping through the unwinder to find out why.
> 
> Andrew.

Andrew,
   Can you walk me through the process of stepping through the unwinder?
Is there a good breakpoint to set so that the process of stepping through
the unwinder isn't so painful. I think we should start with darwin9 since
it will be using the FSF libgcc's unwinder. Thanks in advance for any
advice.
           Jack


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