Re: [patch] Fix oddity in personality routine

Jack Howarth <[email protected]>
Newsgroups gmane.comp.gcc.java.devel
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.