[patch] Fix oddity in personality routine

[patch] Fix oddity in personality routine

[Eric Botcazou]

[-- Attachment #1: Type: text/plain, Size: 887 bytes --]

Hi,

r128098 has introduced an oddity in the personality routine:

  int ip_before_insn = 0;
[...]

  // Parse the LSDA header.
  p = parse_lsda_header (context, language_specific_data, &info);
#ifdef HAVE_GETIPINFO
  ip = _Unwind_GetIPInfo (context, &ip_before_insn);
#else
  ip = _Unwind_GetIP (context) - 1;
#endif
  if (! ip_before_insn)
    --ip;

So, if !HAVE_GETIPINFO, the IP is decremented by 2!  It used to be 1 and both 
libstdc++-v3/libsupc++/eh_personality.cc and ada/raise-gcc.c have the expected 
version:

#ifdef _GLIBCXX_HAVE_GETIPINFO
  ip = _Unwind_GetIPInfo (context, &ip_before_insn);
#else
  ip = _Unwind_GetIP (context);
#endif
  if (! ip_before_insn)
    --ip;

Hence the attached patch, that I don't plan to test though.  OK anyway?


2009-11-13  Eric Botcazou  <ebotcazou@adacore.com>

	* exception.cc (PERSONALITY_FUNCTION): Fix oversight.


-- 
Eric Botcazou

[-- Attachment #2: p.diff --]
[-- Type: text/x-diff, Size: 408 bytes --]

Index: exception.cc
===================================================================
--- exception.cc	(revision 154059)
+++ exception.cc	(working copy)
@@ -328,7 +328,7 @@ PERSONALITY_FUNCTION (int version,
 #ifdef HAVE_GETIPINFO
   ip = _Unwind_GetIPInfo (context, &ip_before_insn);
 #else
-  ip = _Unwind_GetIP (context) - 1;
+  ip = _Unwind_GetIP (context);
 #endif
   if (! ip_before_insn)
     --ip;

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Eric Botcazou wrote:
> Hi,
> 
> r128098 has introduced an oddity in the personality routine:
> 
>   int ip_before_insn = 0;
> [...]
> 
>   // Parse the LSDA header.
>   p = parse_lsda_header (context, language_specific_data, &info);
> #ifdef HAVE_GETIPINFO
>   ip = _Unwind_GetIPInfo (context, &ip_before_insn);
> #else
>   ip = _Unwind_GetIP (context) - 1;
> #endif
>   if (! ip_before_insn)
>     --ip;
> 
> So, if !HAVE_GETIPINFO, the IP is decremented by 2!  It used to be 1 and both 
> libstdc++-v3/libsupc++/eh_personality.cc and ada/raise-gcc.c have the expected 
> version:
> 
> #ifdef _GLIBCXX_HAVE_GETIPINFO
>   ip = _Unwind_GetIPInfo (context, &ip_before_insn);
> #else
>   ip = _Unwind_GetIP (context);
> #endif
>   if (! ip_before_insn)
>     --ip;
> 
> Hence the attached patch, that I don't plan to test though.  OK anyway?
> 
> 
> 2009-11-13  Eric Botcazou  <ebotcazou@adacore.com>
> 
> 	* exception.cc (PERSONALITY_FUNCTION): Fix oversight.
> 


Yes, I think that's right.

Andrew.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Fri, Nov 13, 2009 at 05:57:03PM +0000, Andrew Haley wrote:
> Eric Botcazou wrote:
> > Hi,
> > 
> > r128098 has introduced an oddity in the personality routine:
> > 
> >   int ip_before_insn = 0;
> > [...]
> > 
> >   // Parse the LSDA header.
> >   p = parse_lsda_header (context, language_specific_data, &info);
> > #ifdef HAVE_GETIPINFO
> >   ip = _Unwind_GetIPInfo (context, &ip_before_insn);
> > #else
> >   ip = _Unwind_GetIP (context) - 1;
> > #endif
> >   if (! ip_before_insn)
> >     --ip;
> > 
> > So, if !HAVE_GETIPINFO, the IP is decremented by 2!  It used to be 1 and both 
> > libstdc++-v3/libsupc++/eh_personality.cc and ada/raise-gcc.c have the expected 
> > version:
> > 
> > #ifdef _GLIBCXX_HAVE_GETIPINFO
> >   ip = _Unwind_GetIPInfo (context, &ip_before_insn);
> > #else
> >   ip = _Unwind_GetIP (context);
> > #endif
> >   if (! ip_before_insn)
> >     --ip;
> > 
> > Hence the attached patch, that I don't plan to test though.  OK anyway?
> > 
> > 
> > 2009-11-13  Eric Botcazou  <ebotcazou@adacore.com>
> > 
> > 	* exception.cc (PERSONALITY_FUNCTION): Fix oversight.
> > 
> 
> 
> Yes, I think that's right.
> 
> Andrew.

Andrew,
   Do you think this could be the origin of the problems we have had
on intel darwin with gcj compiling java files? 
                          Jack

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Jack Howarth wrote:
> On Fri, Nov 13, 2009 at 05:57:03PM +0000, Andrew Haley wrote:
>> Eric Botcazou wrote:

>>>
>>> Hence the attached patch, that I don't plan to test though.  OK anyway?
>>>
>>>
>>> 2009-11-13  Eric Botcazou  <ebotcazou@adacore.com>
>>>
>>> 	* exception.cc (PERSONALITY_FUNCTION): Fix oversight.
>>>
>>
>> Yes, I think that's right.
=
>    Do you think this could be the origin of the problems we have had
> on intel darwin with gcj compiling java files? 

Perhaps.  I never guess such things: I always attach a debugger.

Andrew.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Fri, Nov 13, 2009 at 06:50:03PM +0100, Eric Botcazou wrote:
> Hi,
> 
> r128098 has introduced an oddity in the personality routine:
> 
>   int ip_before_insn = 0;
> [...]
> 
>   // Parse the LSDA header.
>   p = parse_lsda_header (context, language_specific_data, &info);
> #ifdef HAVE_GETIPINFO
>   ip = _Unwind_GetIPInfo (context, &ip_before_insn);
> #else
>   ip = _Unwind_GetIP (context) - 1;
> #endif
>   if (! ip_before_insn)
>     --ip;
> 
> So, if !HAVE_GETIPINFO, the IP is decremented by 2!  It used to be 1 and both 
> libstdc++-v3/libsupc++/eh_personality.cc and ada/raise-gcc.c have the expected 
> version:
> 
> #ifdef _GLIBCXX_HAVE_GETIPINFO
>   ip = _Unwind_GetIPInfo (context, &ip_before_insn);
> #else
>   ip = _Unwind_GetIP (context);
> #endif
>   if (! ip_before_insn)
>     --ip;
> 
> Hence the attached patch, that I don't plan to test though.  OK anyway?
> 
> 
> 2009-11-13  Eric Botcazou  <ebotcazou@adacore.com>
> 
> 	* exception.cc (PERSONALITY_FUNCTION): Fix oversight.
> 
> 
> -- 
> Eric Botcazou

> Index: exception.cc
> ===================================================================
> --- exception.cc	(revision 154059)
> +++ exception.cc	(working copy)
> @@ -328,7 +328,7 @@ PERSONALITY_FUNCTION (int version,
>  #ifdef HAVE_GETIPINFO
>    ip = _Unwind_GetIPInfo (context, &ip_before_insn);
>  #else
> -  ip = _Unwind_GetIP (context) - 1;
> +  ip = _Unwind_GetIP (context);
>  #endif
>    if (! ip_before_insn)
>      --ip;


Shouldn't this fix also get backported to gcc-4_4-branch and 
gcc-4_3-branch as well? They both have r128098.
               Jack

Re: [patch] Fix oddity in personality routine

[Bryce McKinlay]

On Fri, Nov 13, 2009 at 7:17 PM, Jack Howarth <howarth@bromo.med.uc.edu> wrote:

>> Index: exception.cc
>> ===================================================================
>> --- exception.cc      (revision 154059)
>> +++ exception.cc      (working copy)
>> @@ -328,7 +328,7 @@ PERSONALITY_FUNCTION (int version,
>>  #ifdef HAVE_GETIPINFO
>>    ip = _Unwind_GetIPInfo (context, &ip_before_insn);
>>  #else
>> -  ip = _Unwind_GetIP (context) - 1;
>> +  ip = _Unwind_GetIP (context);
>>  #endif
>>    if (! ip_before_insn)
>>      --ip;
>
>
> Shouldn't this fix also get backported to gcc-4_4-branch and
> gcc-4_3-branch as well? They both have r128098.

Jack, can you confirm that this actually fixes the problem you are
seeing on Darwin? r128098 dates from 2007 - it's hard to believe that
nobody has had a working GCJ on Darwin since then!

Bryce

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Sun, Nov 15, 2009 at 11:01:22PM +0000, Bryce McKinlay wrote:
> On Fri, Nov 13, 2009@7:17 PM, Jack Howarth <howarth@bromo.med.uc.edu> wrote:
> 
> >> Index: exception.cc
> >> ===================================================================
> >> --- exception.cc      (revision 154059)
> >> +++ exception.cc      (working copy)
> >> @@ -328,7 +328,7 @@ PERSONALITY_FUNCTION (int version,
> >>  #ifdef HAVE_GETIPINFO
> >>    ip = _Unwind_GetIPInfo (context, &ip_before_insn);
> >>  #else
> >> -  ip = _Unwind_GetIP (context) - 1;
> >> +  ip = _Unwind_GetIP (context);
> >>  #endif
> >>    if (! ip_before_insn)
> >>      --ip;
> >
> >
> > Shouldn't this fix also get backported to gcc-4_4-branch and
> > gcc-4_3-branch as well? They both have r128098.
> 
> Jack, can you confirm that this actually fixes the problem you are
> seeing on Darwin? r128098 dates from 2007 - it's hard to believe that
> nobody has had a working GCJ on Darwin since then!
> 
> Bryce

Bryce
   Unfortunately, r154159 didn't eliminate the crashes on x86_64-apple-darwin9
or x86_64-apple-darwin10 when compiling java code with gcj on either a Core2Duo
or Xeon. Oddly...

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

fixes the issue for Andreas Tobler. I am wondering if this is really just
tending the problem to go latent under certain conditions though. Also, the
Makefile.in and Makefile.am still seem a bit odd to me...

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

Using variables before they are actually assigned in Makefiles can't be
right. I wonder if the same issues exist elsewhere in the libjava build
infrastructure.
                   Jack
ps I still ought to test the patch in comment 10 under x86_64-apple-darwin9
(as I only tested with x86_64-apple-darwin10). The darwin10 build has
the additional complexity that the FSF libgcc isn't ever really used since
Apple has subsumed libgcc into libSystem and favors those symbols over
any in libgcc. So the unwinder in libSystem is always used under darwin10
regardless of which libgcc is linked in.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

   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 at 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 at the moment) with
regard to the ecjx linkage flags.

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

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 at 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 at 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.

Andrew.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Mon, Nov 16, 2009 at 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 at 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 at 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.
> 
> Andrew.

Andrew,
   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.
Looking at the output from gdb in comment 1, I notice that patch to ecj.jar is nowhere shown.
This isn't surprising since the current Makefile.in/am use ecjx_LDFLAGS before it is even
assigned. I wonder if we shouldn't work through all of these on the off chance that this is
the accumulation of a number of different build errors like that.
             Jack

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Jack Howarth wrote:
> On Mon, Nov 16, 2009 at 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 at 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 at 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.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

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

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Jack Howarth wrote:
> 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:

>> 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.

>    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.

There's another unwinder?  Gosh.

Set a bp on '_Jv_Throw' and step through.  You'll need to compile libgcc
with -O0 or you'll go insane.  The unwinder is quite complex, and it takes
a fair while to understand it.

Andrew.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Mon, Nov 16, 2009 at 07:08:49PM +0000, Andrew Haley wrote:
> 
> There's another unwinder?  Gosh.
> 

Andrew,
   It really shouldn't be a shock since with Apple's trajectory
to migrate to clang, it becomes more sensible to have one system
wide unwinder etc in libSystem. Basically from darwin10 onward,
Apple will effectively be using an unwinder derived from gcc 4.2.1.

http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html

This gcj bug however seems to impact darwin9 as well which will use
the FSF libgcc so the problem doesn't seem to be specific to Apple's
unwinder in libSystem in darwin10.
             Jack

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Mon, Nov 16, 2009 at 07:08:49PM +0000, Andrew Haley wrote:
> 
> There's another unwinder?  Gosh.
> 
> Set a bp on '_Jv_Throw' and step through.  You'll need to compile libgcc
> with -O0 or you'll go insane.  The unwinder is quite complex, and it takes
> a fair while to understand it.
> 
> Andrew.

Andrew,
   I have added an unwinder_walk.txt attachment to PR41991. It is a walk
from the _Jv_Throw breakpoint for ecj1 compiling the testme.java test code
with a libgcc compiled with -O0 installed. This is with current gcc trunk
using the patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3
compiled on x86_64-apple-darwin9.8.0 to make sure that the FSF libgcc is
used. Hopefully a fix can be found in the libjava code that calls the
unwinder as fixing this within the unwinder won't help us with darwin10
or later.
            Jack

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Jack Howarth wrote:
> On Mon, Nov 16, 2009 at 07:08:49PM +0000, Andrew Haley wrote:
>> There's another unwinder?  Gosh.
>>
>> Set a bp on '_Jv_Throw' and step through.  You'll need to compile libgcc
>> with -O0 or you'll go insane.  The unwinder is quite complex, and it takes
>> a fair while to understand it.

>    I have added an unwinder_walk.txt attachment to PR41991. It is a walk
> from the _Jv_Throw breakpoint for ecj1 compiling the testme.java test code
> with a libgcc compiled with -O0 installed. This is with current gcc trunk
> using the patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3
> compiled on x86_64-apple-darwin9.8.0 to make sure that the FSF libgcc is
> used. Hopefully a fix can be found in the libjava code that calls the
> unwinder as fixing this within the unwinder won't help us with darwin10
> or later.

There's probably nothing wrong with the libjava code that calls the
unwinder: after all, it works everywhere else.  I'm betting this is
bad unwind info.

Anyway, at least this is a start.  It tells us that the stack is
walked but no landing pad is found.  We don't know why.

Andrew.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Tue, Nov 17, 2009 at 10:58:00AM +0000, Andrew Haley wrote:
> Jack Howarth wrote:
> > On Mon, Nov 16, 2009 at 07:08:49PM +0000, Andrew Haley wrote:
> >> There's another unwinder?  Gosh.
> >>
> >> Set a bp on '_Jv_Throw' and step through.  You'll need to compile libgcc
> >> with -O0 or you'll go insane.  The unwinder is quite complex, and it takes
> >> a fair while to understand it.
> 
> >    I have added an unwinder_walk.txt attachment to PR41991. It is a walk
> > from the _Jv_Throw breakpoint for ecj1 compiling the testme.java test code
> > with a libgcc compiled with -O0 installed. This is with current gcc trunk
> > using the patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3
> > compiled on x86_64-apple-darwin9.8.0 to make sure that the FSF libgcc is
> > used. Hopefully a fix can be found in the libjava code that calls the
> > unwinder as fixing this within the unwinder won't help us with darwin10
> > or later.
> 
> There's probably nothing wrong with the libjava code that calls the
> unwinder: after all, it works everywhere else.  I'm betting this is
> bad unwind info.
> 
> Anyway, at least this is a start.  It tells us that the stack is
> walked but no landing pad is found.  We don't know why.
> 
> Andrew.

Andrew,
  In the unwinder walk, are there any particular places where I could
get additional debug information in gdb that would be helpful to diagnose this
issue? Also, what do you make of the fact that the generated libjava Makefile
uses ecjx_LDFLAGS before it is actually assigned...

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

Could this sort of problem be caused by a build issue from improper Makefiles?
Andreas suppressed the crash on his machine using the change in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3 but that is insufficient
to fix it on either my MacBook Pro or MacPro under either darwin9 or darwin10
(which is odd).
                 Jack

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Jack Howarth wrote:
> On Tue, Nov 17, 2009 at 10:58:00AM +0000, Andrew Haley wrote:
>> Jack Howarth wrote:
>>> On Mon, Nov 16, 2009 at 07:08:49PM +0000, Andrew Haley wrote:
>>>> There's another unwinder?  Gosh.
>>>>
>>>> Set a bp on '_Jv_Throw' and step through.  You'll need to compile libgcc
>>>> with -O0 or you'll go insane.  The unwinder is quite complex, and it takes
>>>> a fair while to understand it.
>>>    I have added an unwinder_walk.txt attachment to PR41991. It is a walk
>>> from the _Jv_Throw breakpoint for ecj1 compiling the testme.java test code
>>> with a libgcc compiled with -O0 installed. This is with current gcc trunk
>>> using the patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3
>>> compiled on x86_64-apple-darwin9.8.0 to make sure that the FSF libgcc is
>>> used. Hopefully a fix can be found in the libjava code that calls the
>>> unwinder as fixing this within the unwinder won't help us with darwin10
>>> or later.
>> There's probably nothing wrong with the libjava code that calls the
>> unwinder: after all, it works everywhere else.  I'm betting this is
>> bad unwind info.
>>
>> Anyway, at least this is a start.  It tells us that the stack is
>> walked but no landing pad is found.  We don't know why.

>   In the unwinder walk, are there any particular places where I could
> get additional debug information in gdb that would be helpful to diagnose this
> issue?

Sure.  The trace you provided is very incomplete, and in particular
I can't see any stepping into _Unwind_RaiseException.

The main loop looks like this:

  while (1)
    {
      _Unwind_FrameState fs;

      /* Set up fs to describe the FDE for the caller of cur_context.  The
	 first time through the loop, that means __cxa_throw.  */
      code = uw_frame_state_for (&cur_context, &fs);

      if (code == _URC_END_OF_STACK)
	/* Hit end of stack with no handler found.  */
	return _URC_END_OF_STACK;

      if (code != _URC_NO_REASON)
	/* Some error encountered.  Usually the unwinder doesn't
	   diagnose these and merely crashes.  */
	return _URC_FATAL_PHASE1_ERROR;

      /* Unwind successful.  Run the personality routine, if any.  */
      if (fs.personality)
	{
	  code = (*fs.personality) (1, _UA_SEARCH_PHASE, exc->exception_class,
				    exc, &cur_context);
	  if (code == _URC_HANDLER_FOUND)
	    break;
	  else if (code != _URC_CONTINUE_UNWIND)
	    return _URC_FATAL_PHASE1_ERROR;
	}

      /* Update cur_context to describe the same frame as fs.  */
      uw_update_context (&cur_context, &fs);
    }

So, for each stack frame, we read the unwinder data and then call the
appropriate personality routine (in this case, in libgcj.)

cur_context.ra is the program counter for the current stack frame.
So,

(gdb) x cur_context.ra
0x7ffff659ca7f <_ZN4java3net14URLClassLoader9findClassEJPNS_4lang5ClassEPNS2_6StringE+255>:	0x41c58949

tells you which frame is being inspected.  So, you can see where the
exception handler should be, and you can step into the personality
routine to see why it's not recognized.

> Also, what do you make of the fact that the generated libjava Makefile
> uses ecjx_LDFLAGS before it is actually assigned...
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c10

That's probably not right.

> Could this sort of problem be caused by a build issue from improper Makefiles?

Sorry, I hate to speculate.  I simply don't know.

> Andreas suppressed the crash on his machine using the change in
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3 but that is insufficient
> to fix it on either my MacBook Pro or MacPro under either darwin9 or darwin10
> (which is odd).

It may be a completely different problem.  He's seeing a SEGV, you're not.

Andrew.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Tue, Nov 17, 2009 at 02:54:53PM +0000, Andrew Haley wrote:
> Jack Howarth wrote:
> 
> >   In the unwinder walk, are there any particular places where I could
> > get additional debug information in gdb that would be helpful to diagnose this
> > issue?
> 
> Sure.  The trace you provided is very incomplete, and in particular
> I can't see any stepping into _Unwind_RaiseException.
> 
> The main loop looks like this:
> 
>   while (1)
>     {
>       _Unwind_FrameState fs;
> 
>       /* Set up fs to describe the FDE for the caller of cur_context.  The
> 	 first time through the loop, that means __cxa_throw.  */
>       code = uw_frame_state_for (&cur_context, &fs);
> 
>       if (code == _URC_END_OF_STACK)
> 	/* Hit end of stack with no handler found.  */
> 	return _URC_END_OF_STACK;
> 
>       if (code != _URC_NO_REASON)
> 	/* Some error encountered.  Usually the unwinder doesn't
> 	   diagnose these and merely crashes.  */
> 	return _URC_FATAL_PHASE1_ERROR;
> 
>       /* Unwind successful.  Run the personality routine, if any.  */
>       if (fs.personality)
> 	{
> 	  code = (*fs.personality) (1, _UA_SEARCH_PHASE, exc->exception_class,
> 				    exc, &cur_context);
> 	  if (code == _URC_HANDLER_FOUND)
> 	    break;
> 	  else if (code != _URC_CONTINUE_UNWIND)
> 	    return _URC_FATAL_PHASE1_ERROR;
> 	}
> 
>       /* Update cur_context to describe the same frame as fs.  */
>       uw_update_context (&cur_context, &fs);
>     }
> 
> So, for each stack frame, we read the unwinder data and then call the
> appropriate personality routine (in this case, in libgcj.)
> 
> cur_context.ra is the program counter for the current stack frame.
> So,
> 
> (gdb) x cur_context.ra
> 0x7ffff659ca7f <_ZN4java3net14URLClassLoader9findClassEJPNS_4lang5ClassEPNS2_6StringE+255>:	0x41c58949
> 
> tells you which frame is being inspected.  So, you can see where the
> exception handler should be, and you can step into the personality
> routine to see why it's not recognized.
> 
Andrew,
    At which points should I be sampling with 'x cur_context.ra'? Is there a particular
breakpoint that would be useful to set in order to do this? Also, would it help if I
recompiled libgcj with -O0 as well?
                        Jack

> 
> Andrew.

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Jack Howarth wrote:
> On Tue, Nov 17, 2009 at 02:54:53PM +0000, Andrew Haley wrote:
>> Jack Howarth wrote:
>>
>>>   In the unwinder walk, are there any particular places where I could
>>> get additional debug information in gdb that would be helpful to diagnose this
>>> issue?
>> Sure.  The trace you provided is very incomplete, and in particular
>> I can't see any stepping into _Unwind_RaiseException.
>>
>> The main loop looks like this:
>>
>>   while (1)
>>     {
>>       _Unwind_FrameState fs;
>>
>>       /* Set up fs to describe the FDE for the caller of cur_context.  The
>> 	 first time through the loop, that means __cxa_throw.  */
>>       code = uw_frame_state_for (&cur_context, &fs);
>>
>>       if (code == _URC_END_OF_STACK)
>> 	/* Hit end of stack with no handler found.  */
>> 	return _URC_END_OF_STACK;
>>
>>       if (code != _URC_NO_REASON)
>> 	/* Some error encountered.  Usually the unwinder doesn't
>> 	   diagnose these and merely crashes.  */
>> 	return _URC_FATAL_PHASE1_ERROR;
>>
>>       /* Unwind successful.  Run the personality routine, if any.  */
>>       if (fs.personality)
>> 	{
>> 	  code = (*fs.personality) (1, _UA_SEARCH_PHASE, exc->exception_class,
>> 				    exc, &cur_context);
>> 	  if (code == _URC_HANDLER_FOUND)
>> 	    break;
>> 	  else if (code != _URC_CONTINUE_UNWIND)
>> 	    return _URC_FATAL_PHASE1_ERROR;
>> 	}
>>
>>       /* Update cur_context to describe the same frame as fs.  */
>>       uw_update_context (&cur_context, &fs);
>>     }
>>
>> So, for each stack frame, we read the unwinder data and then call the
>> appropriate personality routine (in this case, in libgcj.)
>>
>> cur_context.ra is the program counter for the current stack frame.
>> So,
>>
>> (gdb) x cur_context.ra
>> 0x7ffff659ca7f <_ZN4java3net14URLClassLoader9findClassEJPNS_4lang5ClassEPNS2_6StringE+255>:	0x41c58949
>>
>> tells you which frame is being inspected.  So, you can see where the
>> exception handler should be, and you can step into the personality
>> routine to see why it's not recognized.

>     At which points should I be sampling with 'x cur_context.ra'? Is there a particular
> breakpoint that would be useful to set in order to do this?

Before and sfter uw_frame_state_for.  Then step into the personality routine.

> Also, would it help if I
> recompiled libgcj with -O0 as well?

Probably.

Andrew.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Tue, Nov 17, 2009 at 02:54:53PM +0000, Andrew Haley wrote:
> Jack Howarth wrote:
> > On Tue, Nov 17, 2009 at 10:58:00AM +0000, Andrew Haley wrote:
> >> Jack Howarth wrote:
> >>> On Mon, Nov 16, 2009 at 07:08:49PM +0000, Andrew Haley wrote:
> >>>> There's another unwinder?  Gosh.
> >>>>
> >>>> Set a bp on '_Jv_Throw' and step through.  You'll need to compile libgcc
> >>>> with -O0 or you'll go insane.  The unwinder is quite complex, and it takes
> >>>> a fair while to understand it.
> >>>    I have added an unwinder_walk.txt attachment to PR41991. It is a walk
> >>> from the _Jv_Throw breakpoint for ecj1 compiling the testme.java test code
> >>> with a libgcc compiled with -O0 installed. This is with current gcc trunk
> >>> using the patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3
> >>> compiled on x86_64-apple-darwin9.8.0 to make sure that the FSF libgcc is
> >>> used. Hopefully a fix can be found in the libjava code that calls the
> >>> unwinder as fixing this within the unwinder won't help us with darwin10
> >>> or later.
> >> There's probably nothing wrong with the libjava code that calls the
> >> unwinder: after all, it works everywhere else.  I'm betting this is
> >> bad unwind info.
> >>
> >> Anyway, at least this is a start.  It tells us that the stack is
> >> walked but no landing pad is found.  We don't know why.
> 
> >   In the unwinder walk, are there any particular places where I could
> > get additional debug information in gdb that would be helpful to diagnose this
> > issue?
> 
> Sure.  The trace you provided is very incomplete, and in particular
> I can't see any stepping into _Unwind_RaiseException.
> 
Andrew,
   One question about the absence of stepping into _Unwind_RaiseException.
Am I doing the walk incorrectly? The steps I used were...

1) gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1
2) (gdb) break _Jv_Throw
3) r testme.java -fbootclasspath=./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccnFt6vF.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccrNgp0M.jar
4) (gdb) s
5) repeatedly hit return to continue stepping through the code

Is there something wrong with that approach which would have kept me
from walking into Unwind_RaiseException? I assume that gcc trunk's
debug code is still compatible with Apple's gdb. If not, I do have
a build of gdb 7.0 on Intel darwin that I can use instead. Thanks
in advance for any hints on this issue.
              Jack
ps I do notice that gdb can't find the object files from /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax so it might have problems with debugging within libgcj. If I recall correctly this .lax issue is known...

http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html



> The main loop looks like this:
> 
>   while (1)
>     {
>       _Unwind_FrameState fs;
> 
>       /* Set up fs to describe the FDE for the caller of cur_context.  The
> 	 first time through the loop, that means __cxa_throw.  */
>       code = uw_frame_state_for (&cur_context, &fs);
> 
>       if (code == _URC_END_OF_STACK)
> 	/* Hit end of stack with no handler found.  */
> 	return _URC_END_OF_STACK;
> 
>       if (code != _URC_NO_REASON)
> 	/* Some error encountered.  Usually the unwinder doesn't
> 	   diagnose these and merely crashes.  */
> 	return _URC_FATAL_PHASE1_ERROR;
> 
>       /* Unwind successful.  Run the personality routine, if any.  */
>       if (fs.personality)
> 	{
> 	  code = (*fs.personality) (1, _UA_SEARCH_PHASE, exc->exception_class,
> 				    exc, &cur_context);
> 	  if (code == _URC_HANDLER_FOUND)
> 	    break;
> 	  else if (code != _URC_CONTINUE_UNWIND)
> 	    return _URC_FATAL_PHASE1_ERROR;
> 	}
> 
>       /* Update cur_context to describe the same frame as fs.  */
>       uw_update_context (&cur_context, &fs);
>     }
> 
> So, for each stack frame, we read the unwinder data and then call the
> appropriate personality routine (in this case, in libgcj.)
> 
> cur_context.ra is the program counter for the current stack frame.
> So,
> 
> (gdb) x cur_context.ra
> 0x7ffff659ca7f <_ZN4java3net14URLClassLoader9findClassEJPNS_4lang5ClassEPNS2_6StringE+255>:	0x41c58949
> 
> tells you which frame is being inspected.  So, you can see where the
> exception handler should be, and you can step into the personality
> routine to see why it's not recognized.
> 
> > Also, what do you make of the fact that the generated libjava Makefile
> > uses ecjx_LDFLAGS before it is actually assigned...
> > 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c10
> 
> That's probably not right.
> 
> > Could this sort of problem be caused by a build issue from improper Makefiles?
> 
> Sorry, I hate to speculate.  I simply don't know.
> 
> > Andreas suppressed the crash on his machine using the change in
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3 but that is insufficient
> > to fix it on either my MacBook Pro or MacPro under either darwin9 or darwin10
> > (which is odd).
> 
> It may be a completely different problem.  He's seeing a SEGV, you're not.
> 
> Andrew.

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Jack Howarth wrote:
> On Tue, Nov 17, 2009 at 02:54:53PM +0000, Andrew Haley wrote:
>> Jack Howarth wrote:
>>> On Tue, Nov 17, 2009 at 10:58:00AM +0000, Andrew Haley wrote:
>>>> Jack Howarth wrote:
>>>>> On Mon, Nov 16, 2009 at 07:08:49PM +0000, Andrew Haley wrote:
>>>>>> There's another unwinder?  Gosh.
>>>>>>
>>>>>> Set a bp on '_Jv_Throw' and step through.  You'll need to compile libgcc
>>>>>> with -O0 or you'll go insane.  The unwinder is quite complex, and it takes
>>>>>> a fair while to understand it.
>>>>>    I have added an unwinder_walk.txt attachment to PR41991. It is a walk
>>>>> from the _Jv_Throw breakpoint for ecj1 compiling the testme.java test code
>>>>> with a libgcc compiled with -O0 installed. This is with current gcc trunk
>>>>> using the patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3
>>>>> compiled on x86_64-apple-darwin9.8.0 to make sure that the FSF libgcc is
>>>>> used. Hopefully a fix can be found in the libjava code that calls the
>>>>> unwinder as fixing this within the unwinder won't help us with darwin10
>>>>> or later.
>>>> There's probably nothing wrong with the libjava code that calls the
>>>> unwinder: after all, it works everywhere else.  I'm betting this is
>>>> bad unwind info.
>>>>
>>>> Anyway, at least this is a start.  It tells us that the stack is
>>>> walked but no landing pad is found.  We don't know why.
>>>   In the unwinder walk, are there any particular places where I could
>>> get additional debug information in gdb that would be helpful to diagnose this
>>> issue?
>> Sure.  The trace you provided is very incomplete, and in particular
>> I can't see any stepping into _Unwind_RaiseException.
>>
> Andrew,
>    One question about the absence of stepping into _Unwind_RaiseException.
> Am I doing the walk incorrectly? The steps I used were...
> 
> 1) gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1
> 2) (gdb) break _Jv_Throw
> 3) r testme.java -fbootclasspath=./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccnFt6vF.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccrNgp0M.jar
> 4) (gdb) s
> 5) repeatedly hit return to continue stepping through the code
> 
> Is there something wrong with that approach which would have kept me
> from walking into Unwind_RaiseException?

Sometimes it doesn't work, so you have to be inventive.  Try
setting a breakpoint on Unwind_RaiseException, or step a single
instruction at a time when you get to a call.

> I assume that gcc trunk's
> debug code is still compatible with Apple's gdb. If not, I do have
> a build of gdb 7.0 on Intel darwin that I can use instead. Thanks
> in advance for any hints on this issue.
>               Jack
> ps I do notice that gdb can't find the object files from /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax so it might have problems with debugging within libgcj. If I recall correctly this .lax issue is known...
> 
> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html

Ouch.  That will cause gdb breakage, for sure.

Andrew.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Tue, Nov 17, 2009 at 05:13:31PM +0000, Andrew Haley wrote:
> 
> Sometimes it doesn't work, so you have to be inventive.  Try
> setting a breakpoint on Unwind_RaiseException, or step a single
> instruction at a time when you get to a call.
> 
> > I assume that gcc trunk's
> > debug code is still compatible with Apple's gdb. If not, I do have
> > a build of gdb 7.0 on Intel darwin that I can use instead. Thanks
> > in advance for any hints on this issue.
> >               Jack
> > ps I do notice that gdb can't find the object files from /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax so it might have problems with debugging within libgcj. If I recall correctly this .lax issue is known...
> > 
> > http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html
> 
> Ouch.  That will cause gdb breakage, for sure.

Andrew,
   Re-reading Peter's comments in http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html, I think I
may be able to work around the lax issue with the proper setting of LD_LIBRARY to point to 
the shared library in the build directory. I'll see if I can puzzle that one out.
                 Jack
> 
> Andrew.

Re: [patch] Fix oddity in personality routine

[borlum]

Jack Howarth-3 wrote:
> 
> On Tue, Nov 17, 2009 at 05:13:31PM +0000, Andrew Haley wrote:
>> 
>> Sometimes it doesn't work, so you have to be inventive.  Try
>> setting a breakpoint on Unwind_RaiseException, or step a single
>> instruction at a time when you get to a call.
>> 
>> > I assume that gcc trunk's
>> > debug code is still compatible with Apple's gdb. If not, I do have
>> > a build of gdb 7.0 on Intel darwin that I can use instead. Thanks
>> > in advance for any hints on this issue.
>> >               Jack
>> > ps I do notice that gdb can't find the object files from
>> /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax
>> so it might have problems with debugging within libgcj. If I recall
>> correctly this .lax issue is known...
>> > 
>> > http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html
>> 
>> Ouch.  That will cause gdb breakage, for sure.
> 
> Andrew,
>    Re-reading Peter's comments in
> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html, I think I
> may be able to work around the lax issue with the proper setting of
> LD_LIBRARY to point to 
> the shared library in the build directory. I'll see if I can puzzle that
> one out.
>                  Jack
>> 
>> Andrew.
> 
> 

Hey Andrew,

Did you ever solve the problem? I'm having the same rather frustrating
error.

Thomas

-- 
View this message in context: http://old.nabble.com/-patch--Fix-oddity-in-personality-routine-tp26340585p26540588.html
Sent from the gcc - java mailing list archive at Nabble.com.

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

borlum wrote:
> 
> 
> Jack Howarth-3 wrote:
>> On Tue, Nov 17, 2009 at 05:13:31PM +0000, Andrew Haley wrote:
>>> Sometimes it doesn't work, so you have to be inventive.  Try
>>> setting a breakpoint on Unwind_RaiseException, or step a single
>>> instruction at a time when you get to a call.
>>>
>>>> I assume that gcc trunk's
>>>> debug code is still compatible with Apple's gdb. If not, I do have
>>>> a build of gdb 7.0 on Intel darwin that I can use instead. Thanks
>>>> in advance for any hints on this issue.
>>>>               Jack
>>>> ps I do notice that gdb can't find the object files from
>>> /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax
>>> so it might have problems with debugging within libgcj. If I recall
>>> correctly this .lax issue is known...
>>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html
>>> Ouch.  That will cause gdb breakage, for sure.
>> Andrew,
>>    Re-reading Peter's comments in
>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html, I think I
>> may be able to work around the lax issue with the proper setting of
>> LD_LIBRARY to point to 
>> the shared library in the build directory. I'll see if I can puzzle that
>> one out.
>>                  Jack
>>> Andrew.
>>
> 
> Hey Andrew,
> 
> Did you ever solve the problem? I'm having the same rather frustrating
> error.

Not me, no.  I don't have a Darwin system.

Andrew.

Re: [patch] Fix oddity in personality routine

[borlum]

Andrew Haley wrote:
> 
> Not me, no.  I don't have a Darwin system.
> 
> Andrew.
> 

Oh, I guess I wasn't following the thread correctly.. :)

I'm afraid I'm too new to the gcc source to fix it myself, I'll keep my
fingers crossed and sob quietly by myself in the meantime.

Thomas

-- 
View this message in context: http://old.nabble.com/-patch--Fix-oddity-in-personality-routine-tp26340585p26540778.html
Sent from the gcc - java mailing list archive at Nabble.com.

Re: [patch] Fix oddity in personality routine

[Bryce McKinlay]

I did take a quick look at this last week on my Mac and can confirm
that there is a problem.

A couple of observations:

- It seems to effect ecj specifically, other EH tests from the libgcj
testsuite seem to work ok.
- An ecj built by hand (with "gcj -O0 -g ecj.jar
--main=org.eclipse.jdt.internal.compiler.batch.GCCMain") also fails,
so I don't think its a build related bug.

Unfortunately, neither Apple's gdb nor a freshly build gdb 7.0 seem to
work debugging binaries built by gcj head on darwin. gdb 7.0 insists
the binary has no debugging info, and Apple gdb gets multiple "could
not find partial DIE in cache" internal errors and "Previous frame
inner to this frame (gdb could not unwind past this frame)" errors
when you try to backtrace.

If anyone knows how to get a working debugger for gcj on Darwin then
perhaps we can debug this further.

Bryce


On Fri, Nov 27, 2009 at 10:52 AM, borlum <thomas@borlum.dk> wrote:
>
>
>
> Andrew Haley wrote:
>>
>> Not me, no.  I don't have a Darwin system.
>>
>> Andrew.
>>
>
> Oh, I guess I wasn't following the thread correctly.. :)
>
> I'm afraid I'm too new to the gcc source to fix it myself, I'll keep my
> fingers crossed and sob quietly by myself in the meantime.
>
> Thomas
>
> --
> View this message in context: http://old.nabble.com/-patch--Fix-oddity-in-personality-routine-tp26340585p26540778.html
> Sent from the gcc - java mailing list archive at Nabble.com.
>
>

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Fri, Nov 27, 2009 at 02:20:32PM +0000, Bryce McKinlay wrote:
> I did take a quick look at this last week on my Mac and can confirm
> that there is a problem.
> 
> A couple of observations:
> 
> - It seems to effect ecj specifically, other EH tests from the libgcj
> testsuite seem to work ok.
> - An ecj built by hand (with "gcj -O0 -g ecj.jar
> --main=org.eclipse.jdt.internal.compiler.batch.GCCMain") also fails,
> so I don't think its a build related bug.
> 
> Unfortunately, neither Apple's gdb nor a freshly build gdb 7.0 seem to
> work debugging binaries built by gcj head on darwin. gdb 7.0 insists
> the binary has no debugging info, and Apple gdb gets multiple "could
> not find partial DIE in cache" internal errors and "Previous frame
> inner to this frame (gdb could not unwind past this frame)" errors
> when you try to backtrace.
> 
> If anyone knows how to get a working debugger for gcj on Darwin then
> perhaps we can debug this further.
> 
> Bryce
> 
> 
> On Fri, Nov 27, 2009 at 10:52 AM, borlum <thomas@borlum.dk> wrote:
> >
> >
> >
> > Andrew Haley wrote:
> >>
> >> Not me, no.  I don't have a Darwin system.
> >>
> >> Andrew.
> >>
> >
> > Oh, I guess I wasn't following the thread correctly.. :)
> >
> > I'm afraid I'm too new to the gcc source to fix it myself, I'll keep my
> > fingers crossed and sob quietly by myself in the meantime.
> >
> > Thomas
> >
> > --
> > View this message in context: http://old.nabble.com/-patch--Fix-oddity-in-personality-routine-tp26340585p26540778.html
> > Sent from the gcc - java mailing list archive at Nabble.com.
> >
> >

  It may be helpful to apply the proposed patch to eliminate the problem
nulll AT_locations from the dwarf output in FSF gcc trunk...

http://gcc.gnu.org/bugzilla/attachment.cgi?id=19160

Currently, because of PR41473, either we are missing dSYM subdirectories in the build
or, when dsymutil doesn't actually crash, the resulting debug info is hosed. This issue
is fixed with the proposed patch, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473#c85,
so that we have proper debug info to walk through now.
                        Jack

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Fri, Nov 27, 2009 at 10:40:17AM +0000, Andrew Haley wrote:
> borlum wrote:
> > 
> > 
> > Jack Howarth-3 wrote:
> >> On Tue, Nov 17, 2009 at 05:13:31PM +0000, Andrew Haley wrote:
> >>> Sometimes it doesn't work, so you have to be inventive.  Try
> >>> setting a breakpoint on Unwind_RaiseException, or step a single
> >>> instruction at a time when you get to a call.
> >>>
> >>>> I assume that gcc trunk's
> >>>> debug code is still compatible with Apple's gdb. If not, I do have
> >>>> a build of gdb 7.0 on Intel darwin that I can use instead. Thanks
> >>>> in advance for any hints on this issue.
> >>>>               Jack
> >>>> ps I do notice that gdb can't find the object files from
> >>> /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax
> >>> so it might have problems with debugging within libgcj. If I recall
> >>> correctly this .lax issue is known...
> >>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html
> >>> Ouch.  That will cause gdb breakage, for sure.
> >> Andrew,
> >>    Re-reading Peter's comments in
> >> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html, I think I
> >> may be able to work around the lax issue with the proper setting of
> >> LD_LIBRARY to point to 
> >> the shared library in the build directory. I'll see if I can puzzle that
> >> one out.
> >>                  Jack
> >>> Andrew.
> >>
> > 
> > Hey Andrew,
> > 
> > Did you ever solve the problem? I'm having the same rather frustrating
> > error.
> 
> Not me, no.  I don't have a Darwin system.
> 
> Andrew.

Andrew,
    Now that we have a set of patches to fix the breakage in current gcc
trunk to dsymutil, I have uploaded a much more complete walk under x86_64-apple-darwin10.
I haven't managed to walk into _Unwind_Exception() yet but I do see that the 
crash occurs on continuing from the 39th instance of the _Unwind_Exception() breakpoint.
Is there some way I can get the unwinder data from inside of libgcj itself before
the call to _Unwind_Exception()? If the bad unwind information is being generated in
libjava wouldn't it be just as easy to see that from outside of libgcc (before the call
to _Unwind_Exception()?
               Jack

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Jack Howarth wrote:
> On Fri, Nov 27, 2009 at 10:40:17AM +0000, Andrew Haley wrote:
>> borlum wrote:
>>>
>>> Jack Howarth-3 wrote:
>>>> On Tue, Nov 17, 2009 at 05:13:31PM +0000, Andrew Haley wrote:
>>>>> Sometimes it doesn't work, so you have to be inventive.  Try
>>>>> setting a breakpoint on Unwind_RaiseException, or step a single
>>>>> instruction at a time when you get to a call.
>>>>>
>>>>>> I assume that gcc trunk's
>>>>>> debug code is still compatible with Apple's gdb. If not, I do have
>>>>>> a build of gdb 7.0 on Intel darwin that I can use instead. Thanks
>>>>>> in advance for any hints on this issue.
>>>>>>               Jack
>>>>>> ps I do notice that gdb can't find the object files from
>>>>> /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax
>>>>> so it might have problems with debugging within libgcj. If I recall
>>>>> correctly this .lax issue is known...
>>>>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html
>>>>> Ouch.  That will cause gdb breakage, for sure.
>>>> Andrew,
>>>>    Re-reading Peter's comments in
>>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html, I think I
>>>> may be able to work around the lax issue with the proper setting of
>>>> LD_LIBRARY to point to 
>>>> the shared library in the build directory. I'll see if I can puzzle that
>>>> one out.
>>>>                  Jack
>>>>> Andrew.
>>> Hey Andrew,
>>>
>>> Did you ever solve the problem? I'm having the same rather frustrating
>>> error.
>> Not me, no.  I don't have a Darwin system.

>     Now that we have a set of patches to fix the breakage in current gcc
> trunk to dsymutil, I have uploaded a much more complete walk under x86_64-apple-darwin10.
> I haven't managed to walk into _Unwind_Exception() yet but I do see that the 
> crash occurs on continuing from the 39th instance of the _Unwind_Exception() breakpoint.

That's probably just the end of the stack.  If you do a stack trace
in gdb you'll probably find it's something like 39 deep.

> Is there some way I can get the unwinder data from inside of libgcj itself before
> the call to _Unwind_Exception()? If the bad unwind information is being generated in
> libjava wouldn't it be just as easy to see that from outside of libgcc (before the call
> to _Unwind_Exception()?

You mean decoding the unwinder data by hand?  It's not impossible, but
it'd be a hell of a job.

Andrew.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Sat, Nov 28, 2009 at 10:43:26AM +0000, Andrew Haley wrote:
> Jack Howarth wrote:
> > On Fri, Nov 27, 2009 at 10:40:17AM +0000, Andrew Haley wrote:
> >> borlum wrote:
> >>>
> >>> Jack Howarth-3 wrote:
> >>>> On Tue, Nov 17, 2009 at 05:13:31PM +0000, Andrew Haley wrote:
> >>>>> Sometimes it doesn't work, so you have to be inventive.  Try
> >>>>> setting a breakpoint on Unwind_RaiseException, or step a single
> >>>>> instruction at a time when you get to a call.
> >>>>>
> >>>>>> I assume that gcc trunk's
> >>>>>> debug code is still compatible with Apple's gdb. If not, I do have
> >>>>>> a build of gdb 7.0 on Intel darwin that I can use instead. Thanks
> >>>>>> in advance for any hints on this issue.
> >>>>>>               Jack
> >>>>>> ps I do notice that gdb can't find the object files from
> >>>>> /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax
> >>>>> so it might have problems with debugging within libgcj. If I recall
> >>>>> correctly this .lax issue is known...
> >>>>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html
> >>>>> Ouch.  That will cause gdb breakage, for sure.
> >>>> Andrew,
> >>>>    Re-reading Peter's comments in
> >>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html, I think I
> >>>> may be able to work around the lax issue with the proper setting of
> >>>> LD_LIBRARY to point to 
> >>>> the shared library in the build directory. I'll see if I can puzzle that
> >>>> one out.
> >>>>                  Jack
> >>>>> Andrew.
> >>> Hey Andrew,
> >>>
> >>> Did you ever solve the problem? I'm having the same rather frustrating
> >>> error.
> >> Not me, no.  I don't have a Darwin system.
> 
> >     Now that we have a set of patches to fix the breakage in current gcc
> > trunk to dsymutil, I have uploaded a much more complete walk under x86_64-apple-darwin10.
> > I haven't managed to walk into _Unwind_Exception() yet but I do see that the 
> > crash occurs on continuing from the 39th instance of the _Unwind_Exception() breakpoint.
> 
> That's probably just the end of the stack.  If you do a stack trace
> in gdb you'll probably find it's something like 39 deep.
> 
> > Is there some way I can get the unwinder data from inside of libgcj itself before
> > the call to _Unwind_Exception()? If the bad unwind information is being generated in
> > libjava wouldn't it be just as easy to see that from outside of libgcc (before the call
> > to _Unwind_Exception()?
> 
> You mean decoding the unwinder data by hand?  It's not impossible, but
> it'd be a hell of a job.
> 
> Andrew.

Andrew,
   I managed to get a build of libgcc at -O0 under darwin9 that I used to walk through
the FSF gcc unwinder. The walk is at...

http://gcc.gnu.org/bugzilla/attachment.cgi?id=19174

and the list of the frames is at...

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

Does this clarify the problem at all on intel darwin? Let me know if there
is any other particular debug information I can provide.
                  Jack

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Jack Howarth wrote:
> On Sat, Nov 28, 2009 at 10:43:26AM +0000, Andrew Haley wrote:
>> Jack Howarth wrote:
>>> On Fri, Nov 27, 2009 at 10:40:17AM +0000, Andrew Haley wrote:
>>>> borlum wrote:
>>>>> Jack Howarth-3 wrote:
>>>>>> On Tue, Nov 17, 2009 at 05:13:31PM +0000, Andrew Haley wrote:
>>>>>>> Sometimes it doesn't work, so you have to be inventive.  Try
>>>>>>> setting a breakpoint on Unwind_RaiseException, or step a single
>>>>>>> instruction at a time when you get to a call.
>>>>>>>
>>>>>>>> I assume that gcc trunk's
>>>>>>>> debug code is still compatible with Apple's gdb. If not, I do have
>>>>>>>> a build of gdb 7.0 on Intel darwin that I can use instead. Thanks
>>>>>>>> in advance for any hints on this issue.
>>>>>>>>               Jack
>>>>>>>> ps I do notice that gdb can't find the object files from
>>>>>>> /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax
>>>>>>> so it might have problems with debugging within libgcj. If I recall
>>>>>>> correctly this .lax issue is known...
>>>>>>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html
>>>>>>> Ouch.  That will cause gdb breakage, for sure.
>>>>>> Andrew,
>>>>>>    Re-reading Peter's comments in
>>>>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html, I think I
>>>>>> may be able to work around the lax issue with the proper setting of
>>>>>> LD_LIBRARY to point to 
>>>>>> the shared library in the build directory. I'll see if I can puzzle that
>>>>>> one out.
>>>>>>                  Jack
>>>>>>> Andrew.
>>>>> Hey Andrew,
>>>>>
>>>>> Did you ever solve the problem? I'm having the same rather frustrating
>>>>> error.
>>>> Not me, no.  I don't have a Darwin system.
>>>     Now that we have a set of patches to fix the breakage in current gcc
>>> trunk to dsymutil, I have uploaded a much more complete walk under x86_64-apple-darwin10.
>>> I haven't managed to walk into _Unwind_Exception() yet but I do see that the 
>>> crash occurs on continuing from the 39th instance of the _Unwind_Exception() breakpoint.
>> That's probably just the end of the stack.  If you do a stack trace
>> in gdb you'll probably find it's something like 39 deep.
>>
>>> Is there some way I can get the unwinder data from inside of libgcj itself before
>>> the call to _Unwind_Exception()? If the bad unwind information is being generated in
>>> libjava wouldn't it be just as easy to see that from outside of libgcc (before the call
>>> to _Unwind_Exception()?
>> You mean decoding the unwinder data by hand?  It's not impossible, but
>> it'd be a hell of a job.
>>
>    I managed to get a build of libgcc at -O0 under darwin9 that I used to walk through
> the FSF gcc unwinder. The walk is at...
> 
> http://gcc.gnu.org/bugzilla/attachment.cgi?id=19174
> 
> and the list of the frames is at...
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c26
> 
> Does this clarify the problem at all on intel darwin? Let me know if there
> is any other particular debug information I can provide.

It stops when unwinding java.lang.ClassLoader.loadClass(java.lang.String, boolean),
either because the unwinder data is buggy (probably) or because the unwinder
itself is buggy.

It's hard to be exactly clear what's going wrong, but it may be that the place
it fails is at the point where the program calls libgcj.

Andrew.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Sun, Nov 29, 2009 at 06:00:57PM +0000, Andrew Haley wrote:
> Jack Howarth wrote:
> > On Sat, Nov 28, 2009 at 10:43:26AM +0000, Andrew Haley wrote:
> >> Jack Howarth wrote:
> >>> On Fri, Nov 27, 2009 at 10:40:17AM +0000, Andrew Haley wrote:
> >>>> borlum wrote:
> >>>>> Jack Howarth-3 wrote:
> >>>>>> On Tue, Nov 17, 2009 at 05:13:31PM +0000, Andrew Haley wrote:
> >>>>>>> Sometimes it doesn't work, so you have to be inventive.  Try
> >>>>>>> setting a breakpoint on Unwind_RaiseException, or step a single
> >>>>>>> instruction at a time when you get to a call.
> >>>>>>>
> >>>>>>>> I assume that gcc trunk's
> >>>>>>>> debug code is still compatible with Apple's gdb. If not, I do have
> >>>>>>>> a build of gdb 7.0 on Intel darwin that I can use instead. Thanks
> >>>>>>>> in advance for any hints on this issue.
> >>>>>>>>               Jack
> >>>>>>>> ps I do notice that gdb can't find the object files from
> >>>>>>> /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax
> >>>>>>> so it might have problems with debugging within libgcj. If I recall
> >>>>>>> correctly this .lax issue is known...
> >>>>>>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html
> >>>>>>> Ouch.  That will cause gdb breakage, for sure.
> >>>>>> Andrew,
> >>>>>>    Re-reading Peter's comments in
> >>>>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html, I think I
> >>>>>> may be able to work around the lax issue with the proper setting of
> >>>>>> LD_LIBRARY to point to 
> >>>>>> the shared library in the build directory. I'll see if I can puzzle that
> >>>>>> one out.
> >>>>>>                  Jack
> >>>>>>> Andrew.
> >>>>> Hey Andrew,
> >>>>>
> >>>>> Did you ever solve the problem? I'm having the same rather frustrating
> >>>>> error.
> >>>> Not me, no.  I don't have a Darwin system.
> >>>     Now that we have a set of patches to fix the breakage in current gcc
> >>> trunk to dsymutil, I have uploaded a much more complete walk under x86_64-apple-darwin10.
> >>> I haven't managed to walk into _Unwind_Exception() yet but I do see that the 
> >>> crash occurs on continuing from the 39th instance of the _Unwind_Exception() breakpoint.
> >> That's probably just the end of the stack.  If you do a stack trace
> >> in gdb you'll probably find it's something like 39 deep.
> >>
> >>> Is there some way I can get the unwinder data from inside of libgcj itself before
> >>> the call to _Unwind_Exception()? If the bad unwind information is being generated in
> >>> libjava wouldn't it be just as easy to see that from outside of libgcc (before the call
> >>> to _Unwind_Exception()?
> >> You mean decoding the unwinder data by hand?  It's not impossible, but
> >> it'd be a hell of a job.
> >>
> >    I managed to get a build of libgcc at -O0 under darwin9 that I used to walk through
> > the FSF gcc unwinder. The walk is at...
> > 
> > http://gcc.gnu.org/bugzilla/attachment.cgi?id=19174
> > 
> > and the list of the frames is at...
> > 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c26
> > 
> > Does this clarify the problem at all on intel darwin? Let me know if there
> > is any other particular debug information I can provide.
> 
> It stops when unwinding java.lang.ClassLoader.loadClass(java.lang.String, boolean),
> either because the unwinder data is buggy (probably) or because the unwinder
> itself is buggy.

  Would it help if I just used a breakpoint on uw_frame_state_for() and provided all
of the unwinding info that is being processed? Might that clarify if the unwinder
data is buggy?
                                 Jack
> 
> It's hard to be exactly clear what's going wrong, but it may be that the place
> it fails is at the point where the program calls libgcj.
> 
> Andrew.

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Jack Howarth wrote:
> On Sun, Nov 29, 2009 at 06:00:57PM +0000, Andrew Haley wrote:
>> Jack Howarth wrote:
>>> On Sat, Nov 28, 2009 at 10:43:26AM +0000, Andrew Haley wrote:
>>>> Jack Howarth wrote:
>>>>> On Fri, Nov 27, 2009 at 10:40:17AM +0000, Andrew Haley wrote:

>>>>
>>>    I managed to get a build of libgcc at -O0 under darwin9 that I used to walk through
>>> the FSF gcc unwinder. The walk is at...
>>>
>>> http://gcc.gnu.org/bugzilla/attachment.cgi?id=19174
>>>
>>> and the list of the frames is at...
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c26
>>>
>>> Does this clarify the problem at all on intel darwin? Let me know if there
>>> is any other particular debug information I can provide.
>> It stops when unwinding java.lang.ClassLoader.loadClass(java.lang.String, boolean),
>> either because the unwinder data is buggy (probably) or because the unwinder
>> itself is buggy.
> 
>   Would it help if I just used a breakpoint on uw_frame_state_for() and provided all
> of the unwinding info that is being processed? Might that clarify if the unwinder
> data is buggy?

Not really, no.  The only thing now is to debug the unwinder at the point
where the exception should be caught.  You're seeing a bus error in the
unwinder itself, which points to a failure to follow the chain of stack
frames.

Andrew.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Mon, Nov 30, 2009 at 10:09:17AM +0000, Andrew Haley wrote:
> Jack Howarth wrote:
> > On Sun, Nov 29, 2009 at 06:00:57PM +0000, Andrew Haley wrote:
> >> Jack Howarth wrote:
> >>> On Sat, Nov 28, 2009 at 10:43:26AM +0000, Andrew Haley wrote:
> >>>> Jack Howarth wrote:
> >>>>> On Fri, Nov 27, 2009 at 10:40:17AM +0000, Andrew Haley wrote:
> 
> >>>>
> >>>    I managed to get a build of libgcc at -O0 under darwin9 that I used to walk through
> >>> the FSF gcc unwinder. The walk is at...
> >>>
> >>> http://gcc.gnu.org/bugzilla/attachment.cgi?id=19174
> >>>
> >>> and the list of the frames is at...
> >>>
> >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c26
> >>>
> >>> Does this clarify the problem at all on intel darwin? Let me know if there
> >>> is any other particular debug information I can provide.
> >> It stops when unwinding java.lang.ClassLoader.loadClass(java.lang.String, boolean),
> >> either because the unwinder data is buggy (probably) or because the unwinder
> >> itself is buggy.
> > 
> >   Would it help if I just used a breakpoint on uw_frame_state_for() and provided all
> > of the unwinding info that is being processed? Might that clarify if the unwinder
> > data is buggy?
> 
> Not really, no.  The only thing now is to debug the unwinder at the point
> where the exception should be caught.  You're seeing a bus error in the
> unwinder itself, which points to a failure to follow the chain of stack
> frames.
> 
> Andrew.

Andrew,
   I'll generate a complete debug walk from the last instance of the
_Unwind_RaiseException breakpoint before the crash tonight. I started
doing that this weekend but it was taking forever to complete the walk.
   What code actually generates the unwind info in gcj? Is it from libffi?
I might also drop back to the gcc 4.3.x releases in darwin9 to see if 
I can detect if this ever worked and if so when it regressed. However,
considering that Andreas has managed to get this to be suppressed at
times, I wonder if this issue has always been present on intel darwin
and just tends to go latent at times.
               Jack
ps It is odd that the unwind info generated for compiling classes with
gcj never seems to cause a problem. Could that be a clue as to the
segment of code at fault? I noticed that the ecjx.c source is a dummy
shell so I was unclear which code is used in gcj to compile java source
but not classes.

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Jack Howarth wrote:
> On Mon, Nov 30, 2009 at 10:09:17AM +0000, Andrew Haley wrote:
>> Jack Howarth wrote:
>>> On Sun, Nov 29, 2009 at 06:00:57PM +0000, Andrew Haley wrote:
>>>> Jack Howarth wrote:
>>>>> On Sat, Nov 28, 2009 at 10:43:26AM +0000, Andrew Haley wrote:
>>>>>> Jack Howarth wrote:
>>>>>>> On Fri, Nov 27, 2009 at 10:40:17AM +0000, Andrew Haley wrote:
>>>>>    I managed to get a build of libgcc at -O0 under darwin9 that I used to walk through
>>>>> the FSF gcc unwinder. The walk is at...
>>>>>
>>>>> http://gcc.gnu.org/bugzilla/attachment.cgi?id=19174
>>>>>
>>>>> and the list of the frames is at...
>>>>>
>>>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c26
>>>>>
>>>>> Does this clarify the problem at all on intel darwin? Let me know if there
>>>>> is any other particular debug information I can provide.
>>>> It stops when unwinding java.lang.ClassLoader.loadClass(java.lang.String, boolean),
>>>> either because the unwinder data is buggy (probably) or because the unwinder
>>>> itself is buggy.
>>>   Would it help if I just used a breakpoint on uw_frame_state_for() and provided all
>>> of the unwinding info that is being processed? Might that clarify if the unwinder
>>> data is buggy?
>> Not really, no.  The only thing now is to debug the unwinder at the point
>> where the exception should be caught.  You're seeing a bus error in the
>> unwinder itself, which points to a failure to follow the chain of stack
>> frames.

>    I'll generate a complete debug walk from the last instance of the
> _Unwind_RaiseException breakpoint before the crash tonight. I started
> doing that this weekend but it was taking forever to complete the walk.
>    What code actually generates the unwind info in gcj?

The gcc back end.

> Is it from libffi?

libffi has its own unwind info.  It's written by hand, and it might be wrong.
look in libffi/x86/darwin64.S.

> I might also drop back to the gcc 4.3.x releases in darwin9 to see if 
> I can detect if this ever worked and if so when it regressed. However,
> considering that Andreas has managed to get this to be suppressed at
> times, I wonder if this issue has always been present on intel darwin
> and just tends to go latent at times.

That's quite possible, for sure.

> ps It is odd that the unwind info generated for compiling classes with
> gcj never seems to cause a problem. Could that be a clue as to the
> segment of code at fault? I noticed that the ecjx.c source is a dummy
> shell so I was unclear which code is used in gcj to compile java source
> but not classes.

I think you really need to concentrate on the instruction that's causing
the bus error.  What is is pointing at?  What it it trying to do?

The other thing that's odd is that there are a number of test cases in
the libgcj test suite that stress the interpreter (and therefore libffi)
quite a lot.  Are you really seeing 100% pass?

Andrew.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

Andrew,
    I have uploaded a bz2 archive of the walk from the
last _Unwind_RaiseException breakpoint before the crash
up to the crash to PR41991. The crash appears at...

_Jv_GetMethodLocal (klass=0x104a298c0, name=0x104af13a0, signature=0x104b1dfe0) at ../../../gcc-4.5-20091128/libjava/java/lang/natClass.cc:1633
1633		  && _Jv_equalUtf8Consts (signature, klass->methods[i].signature))
(gdb) 
_Jv_equalUtf8Consts (a=0x104b1dfe0, b=0x1048262c0) at ../../../gcc-4.5-20091128/libjava/prims.cc:209
209	  if (a == b)
(gdb) 
210	    return true;
(gdb) 
209	  if (a == b)
(gdb) 
211	  if (a->hash != b->hash)
(gdb) 
212	    return false;
(gdb) 
211	  if (a->hash != b->hash)
(gdb) 
214	  if (b->length != len)
(gdb) 
218	  len = (len + 1) >> 1;
(gdb) 
216	  aptr = (const _Jv_ushort *)a->data;
(gdb) 
217	  bptr = (const _Jv_ushort *)b->data;
(gdb) 
218	  len = (len + 1) >> 1;
(gdb) 
219	  while (--len >= 0)
(gdb) 
220	    if (*aptr++ != *bptr++)
(gdb) 
219	  while (--len >= 0)
(gdb) 
220	    if (*aptr++ != *bptr++)
(gdb) 
219	  while (--len >= 0)
(gdb) 
220	    if (*aptr++ != *bptr++)
(gdb) 
219	  while (--len >= 0)
(gdb) 
220	    if (*aptr++ != *bptr++)
(gdb) 
219	  while (--len >= 0)
(gdb) 
220	    if (*aptr++ != *bptr++)
(gdb) 
219	  while (--len >= 0)
(gdb) 
220	    if (*aptr++ != *bptr++)
(gdb) 
219	  while (--len >= 0)
(gdb) 
220	    if (*aptr++ != *bptr++)
(gdb) 
219	  while (--len >= 0)
(gdb) 
220	    if (*aptr++ != *bptr++)
(gdb) 
219	  while (--len >= 0)
(gdb) 
220	    if (*aptr++ != *bptr++)
(gdb) 
219	  while (--len >= 0)
(gdb) 
220	    if (*aptr++ != *bptr++)
(gdb) 
219	  while (--len >= 0)
(gdb) 
220	    if (*aptr++ != *bptr++)
(gdb) 
219	  while (--len >= 0)
(gdb) 
222	  return true;
(gdb) 
223	}
(gdb) 
_Jv_GetMethodLocal (klass=0x104a298c0, name=0x104af13a0, signature=0x104b1dfe0) at ../../../gcc-4.5-20091128/libjava/java/lang/natClass.cc:1632
1632	      if (_Jv_equalUtf8Consts (name, klass->methods[i].name)
(gdb) 
1634		return &klass->methods[i];
(gdb) 
1637	}
(gdb) 
_Jv_LookupDeclaredMethod (klass=0x104a298c0, name=0x104af13a0, signature=0x104b1dfe0, declarer_result=0x0) at ../../../gcc-4.5-20091128/libjava/java/lang/natClass.cc:1648
1648	      if (meth)
(gdb) 
1650		  if (declarer_result)
(gdb) 
1657	}
(gdb) 
gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:41
41	  if (meth == NULL)
(gdb) 
37						       main_signature);
(gdb) 
41	  if (meth == NULL)
(gdb) 
43	  else if (! ::java::lang::reflect::Modifier::isStatic(meth->accflags))
(gdb) 
_ZN4java4lang7reflect8Modifier8isStaticEJbi (mod=9) at Modifier.java:268
268	    return (mod & STATIC) != 0;
(gdb) 
_ZN4java4lang7reflect8Modifier8isStaticEJbi (mod=9) at Modifier.java:268
268	    return (mod & STATIC) != 0;
(gdb) 
0x0000000100994af0 in dyld_stub__Jv_InitClass () at RowSetEvent.java:51
51	RowSetEvent.java: No such file or directory.
	in RowSetEvent.java
(gdb) 
_Jv_InitClass (klass=0x10168ce40) at Class.h:740
740	  if (__builtin_expect (klass->state == JV_STATE_DONE, true))
(gdb) 
743	}
(gdb) 
0x00000001004168bf in _ZN4java4lang7reflect8Modifier8isStaticEJbi (mod=9) at Modifier.java:268
268	    return (mod & STATIC) != 0;
(gdb) 
gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:44
44	    msg = "`main' must be static";
(gdb) 
43	  else if (! ::java::lang::reflect::Modifier::isStatic(meth->accflags))
(gdb) 
45	  else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags))
(gdb) 
_ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258
258	    return (mod & PUBLIC) != 0;
(gdb) 
_ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258
258	    return (mod & PUBLIC) != 0;
(gdb) 
0x0000000100994af0 in dyld_stub__Jv_InitClass () at RowSetEvent.java:51
51	RowSetEvent.java: No such file or directory.
	in RowSetEvent.java
(gdb) 
_Jv_InitClass (klass=0x10168ce40) at Class.h:740
740	  if (__builtin_expect (klass->state == JV_STATE_DONE, true))
(gdb) 
743	}
(gdb) 
0x00000001004168df in _ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258
258	    return (mod & PUBLIC) != 0;
(gdb) 
gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46
46	    msg =  "`main' must be public";
(gdb) 
45	  else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags))
(gdb) 
54	  (*real_main) (args);
(gdb) 

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
0x0000000103f05db0 in ?? () at RowSetEvent.java:51
51	RowSetEvent.java: No such file or directory.
	in RowSetEvent.java
(gdb) 

A backtrace only shows...

(gdb) bt
#0  0x0000000103f05db0 in ?? () at RowSetEvent.java:51
#1  0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
Previous frame inner to this frame (gdb could not unwind past this frame)

Let me know if you have any suggestions for debugging this further.
                      Jack

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Jack Howarth wrote:

> (gdb) 
> 54	  (*real_main) (args);
> (gdb) 
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51
> 51	RowSetEvent.java: No such file or directory.
> 	in RowSetEvent.java
> (gdb) 
> 
> A backtrace only shows...
> 
> (gdb) bt
> #0  0x0000000103f05db0 in ?? () at RowSetEvent.java:51
> #1  0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
> Previous frame inner to this frame (gdb could not unwind past this frame)
> 
> Let me know if you have any suggestions for debugging this further.

Disassemble the first 10 or so instructions at the instruction where the
EXC_BAD_ACCESS occurs.  I think this is a libffi bug.

Andrew.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Tue, Dec 01, 2009 at 09:29:36AM +0000, Andrew Haley wrote:
> Jack Howarth wrote:
> 
> > (gdb) 
> > 54	  (*real_main) (args);
> > (gdb) 
> > 
> > Program received signal EXC_BAD_ACCESS, Could not access memory.
> > Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
> > 0x0000000103f05db0 in ?? () at RowSetEvent.java:51
> > 51	RowSetEvent.java: No such file or directory.
> > 	in RowSetEvent.java
> > (gdb) 
> > 
> > A backtrace only shows...
> > 
> > (gdb) bt
> > #0  0x0000000103f05db0 in ?? () at RowSetEvent.java:51
> > #1  0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
> > Previous frame inner to this frame (gdb could not unwind past this frame)
> > 
> > Let me know if you have any suggestions for debugging this further.
> 
> Disassemble the first 10 or so instructions at the instruction where the
> EXC_BAD_ACCESS occurs.  I think this is a libffi bug.
> 
> Andrew.

Andrew,
   So just to clarify, for the instance of...

-------------------

(gdb) 
0x00000001004168df in _ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258
258	    return (mod & PUBLIC) != 0;
(gdb) 
gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46
46	    msg =  "`main' must be public";
(gdb) 
45	  else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags))
(gdb) 
54	  (*real_main) (args);
(gdb) 

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
0x0000000103f05db0 in ?? () at RowSetEvent.java:51
51	RowSetEvent.java: No such file or directory.
	in RowSetEvent.java
(gdb) 

A backtrace only shows...

(gdb) bt
#0  0x0000000103f05db0 in ?? () at RowSetEvent.java:51
#1  0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
Previous frame inner to this frame (gdb could not unwind past this frame)

-----------------

I want to disassemble from 0x00000001000485be, right?
         Jack

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Jack Howarth wrote:
> On Tue, Dec 01, 2009 at 09:29:36AM +0000, Andrew Haley wrote:
>> Jack Howarth wrote:
>>
>>> (gdb) 
>>> 54	  (*real_main) (args);
>>> (gdb) 
>>>
>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
>>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51
>>> 51	RowSetEvent.java: No such file or directory.
>>> 	in RowSetEvent.java
>>> (gdb) 
>>>
>>> A backtrace only shows...
>>>
>>> (gdb) bt
>>> #0  0x0000000103f05db0 in ?? () at RowSetEvent.java:51
>>> #1  0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
>>> Previous frame inner to this frame (gdb could not unwind past this frame)
>>>
>>> Let me know if you have any suggestions for debugging this further.
>> Disassemble the first 10 or so instructions at the instruction where the
>> EXC_BAD_ACCESS occurs.  I think this is a libffi bug.
>>
>> Andrew.
> 
> Andrew,
>    So just to clarify, for the instance of...
> 
> -------------------
> 
> (gdb) 
> 0x00000001004168df in _ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258
> 258	    return (mod & PUBLIC) != 0;
> (gdb) 
> gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46
> 46	    msg =  "`main' must be public";
> (gdb) 
> 45	  else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags))
> (gdb) 
> 54	  (*real_main) (args);
> (gdb) 
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51
> 51	RowSetEvent.java: No such file or directory.
> 	in RowSetEvent.java
> (gdb) 
> 
> A backtrace only shows...
> 
> (gdb) bt
> #0  0x0000000103f05db0 in ?? () at RowSetEvent.java:51
> #1  0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
> Previous frame inner to this frame (gdb could not unwind past this frame)
> 
> -----------------
> 
> I want to disassemble from 0x00000001000485be, right?

0x0000000103f05db0, where the fault happens.  I think it's a libffi stub,
and I think its page permissions are not correctly set.

But let's see.

What I would do is, at

> 54	  (*real_main) (args);

disassemble the call instruction, it's probably  call ($rax)  or somesuch.
look in $rax with

p $rax

and disassemble from the address that's in there.

Andrew.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Tue, Dec 01, 2009 at 05:24:29PM +0000, Andrew Haley wrote:
> Jack Howarth wrote:
> > On Tue, Dec 01, 2009 at 09:29:36AM +0000, Andrew Haley wrote:
> >> Jack Howarth wrote:
> >>
> >>> (gdb) 
> >>> 54	  (*real_main) (args);
> >>> (gdb) 
> >>>
> >>> Program received signal EXC_BAD_ACCESS, Could not access memory.
> >>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
> >>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51
> >>> 51	RowSetEvent.java: No such file or directory.
> >>> 	in RowSetEvent.java
> >>> (gdb) 
> >>>
> >>> A backtrace only shows...
> >>>
> >>> (gdb) bt
> >>> #0  0x0000000103f05db0 in ?? () at RowSetEvent.java:51
> >>> #1  0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
> >>> Previous frame inner to this frame (gdb could not unwind past this frame)
> >>>
> >>> Let me know if you have any suggestions for debugging this further.
> >> Disassemble the first 10 or so instructions at the instruction where the
> >> EXC_BAD_ACCESS occurs.  I think this is a libffi bug.
> >>
> >> Andrew.
> > 
> > Andrew,
> >    So just to clarify, for the instance of...
> > 
> > -------------------
> > 
> > (gdb) 
> > 0x00000001004168df in _ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258
> > 258	    return (mod & PUBLIC) != 0;
> > (gdb) 
> > gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46
> > 46	    msg =  "`main' must be public";
> > (gdb) 
> > 45	  else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags))
> > (gdb) 
> > 54	  (*real_main) (args);
> > (gdb) 
> > 
> > Program received signal EXC_BAD_ACCESS, Could not access memory.
> > Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
> > 0x0000000103f05db0 in ?? () at RowSetEvent.java:51
> > 51	RowSetEvent.java: No such file or directory.
> > 	in RowSetEvent.java
> > (gdb) 
> > 
> > A backtrace only shows...
> > 
> > (gdb) bt
> > #0  0x0000000103f05db0 in ?? () at RowSetEvent.java:51
> > #1  0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
> > Previous frame inner to this frame (gdb could not unwind past this frame)
> > 
> > -----------------
> > 
> > I want to disassemble from 0x00000001000485be, right?
> 
> 0x0000000103f05db0, where the fault happens.  I think it's a libffi stub,
> and I think its page permissions are not correctly set.
> 
> But let's see.
> 
> What I would do is, at
> 
> > 54	  (*real_main) (args);
> 
> disassemble the call instruction, it's probably  call ($rax)  or somesuch.
> look in $rax with
> 
> p $rax
> 
> and disassemble from the address that's in there.
> 
> Andrew.

Andrew,
   I can't disassemble 0x0000000103f05db0...

(gdb) disassemble 0x0000000103f05db0
No function contains specified address.

Disassembling 0x00000001000485be shows...

(gdb) disassemble 0x00000001000485be
Dump of assembler code for function _ZN3gnu4java4lang10MainThread9call_mainEJvv:
0x00000001000484f0 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+0>:	mov    %rbx,-0x18(%rsp)
0x00000001000484f5 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+5>:	mov    %rdi,%rbx
0x00000001000484f8 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+8>:	lea    0x94f508(%rip),%rdi        # 0x100997a07 <dyld_stub_write+10609>
0x00000001000484ff <_ZN3gnu4java4lang10MainThread9call_mainEJvv+15>:	mov    %rbp,-0x10(%rsp)
0x0000000100048504 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+20>:	mov    %r12,-0x8(%rsp)
0x0000000100048509 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+25>:	mov    $0x16,%esi
0x000000010004850e <_ZN3gnu4java4lang10MainThread9call_mainEJvv+30>:	sub    $0x18,%rsp
0x0000000100048512 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+34>:	callq  0x100005a50 <_Z17_Jv_makeUtf8ConstPKci>
0x0000000100048517 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+39>:	lea    0x94f500(%rip),%rdi        # 0x100997a1e <dyld_stub_write+10632>
0x000000010004851e <_ZN3gnu4java4lang10MainThread9call_mainEJvv+46>:	mov    $0x4,%esi
0x0000000100048523 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+51>:	mov    %rax,%r12
0x0000000100048526 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+54>:	callq  0x100005a50 <_Z17_Jv_makeUtf8ConstPKci>
0x000000010004852b <_ZN3gnu4java4lang10MainThread9call_mainEJvv+59>:	mov    0x80(%rbx),%rdi
0x0000000100048532 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+66>:	mov    $0x3,%esi
0x0000000100048537 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+71>:	mov    %rax,%rbp
0x000000010004853a <_ZN3gnu4java4lang10MainThread9call_mainEJvv+74>:	callq  0x100016830 <_ZN10_Jv_Linker14wait_for_stateEPN4java4lang5ClassEi>
0x000000010004853f <_ZN3gnu4java4lang10MainThread9call_mainEJvv+79>:	mov    0x80(%rbx),%rdi
0x0000000100048546 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+86>:	xor    %ecx,%ecx
0x0000000100048548 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+88>:	mov    %rbp,%rsi
0x000000010004854b <_ZN3gnu4java4lang10MainThread9call_mainEJvv+91>:	mov    %r12,%rdx
0x000000010004854e <_ZN3gnu4java4lang10MainThread9call_mainEJvv+94>:	callq  0x100051b10 <_Z24_Jv_LookupDeclaredMethodPN4java4lang5ClassEP13_Jv_Utf8ConstS4_PS2_>
0x0000000100048553 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+99>:	test   %rax,%rax
0x0000000100048556 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+102>:	mov    %rax,%rbp
0x0000000100048559 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+105>:	je     0x1000485f0 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+256>
0x000000010004855f <_ZN3gnu4java4lang10MainThread9call_mainEJvv+111>:	movzwl 0x10(%rax),%edi
0x0000000100048563 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+115>:	callq  0x1004168b0 <_ZN4java4lang7reflect8Modifier8isStaticEJbi>
0x0000000100048568 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+120>:	test   %al,%al
0x000000010004856a <_ZN3gnu4java4lang10MainThread9call_mainEJvv+122>:	lea    0x94f46a(%rip),%rdx        # 0x1009979db <dyld_stub_write+10565>
0x0000000100048571 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+129>:	jne    0x1000485a0 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+176>
0x0000000100048573 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+131>:	mov    0x1329a96(%rip),%rax        # 0x101372010 <ffi_type_longdouble+48>
0x000000010004857a <_ZN3gnu4java4lang10MainThread9call_mainEJvv+138>:	lea    0x94f4a2(%rip),%rsi        # 0x100997a23 <dyld_stub_write+10637>
0x0000000100048581 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+145>:	mov    (%rax),%rdi
0x0000000100048584 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+148>:	xor    %eax,%eax
0x0000000100048586 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+150>:	callq  0x100994d4e <dyld_stub_fprintf>
0x000000010004858b <_ZN3gnu4java4lang10MainThread9call_mainEJvv+155>:	mov    $0x1,%edi
0x0000000100048590 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+160>:	callq  0x100994d1e <dyld_stub_exit>
0x0000000100048595 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+165>:	nopl   0x0(%rax,%rax,1)
0x000000010004859a <_ZN3gnu4java4lang10MainThread9call_mainEJvv+170>:	nopw   0x0(%rax,%rax,1)
0x00000001000485a0 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+176>:	movzwl 0x10(%rbp),%edi
0x00000001000485a4 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+180>:	callq  0x1004168d0 <_ZN4java4lang7reflect8Modifier8isPublicEJbi>
0x00000001000485a9 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+185>:	test   %al,%al
0x00000001000485ab <_ZN3gnu4java4lang10MainThread9call_mainEJvv+187>:	lea    0x94f43f(%rip),%rdx        # 0x1009979f1 <dyld_stub_write+10587>
0x00000001000485b2 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+194>:	je     0x100048573 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+131>
0x00000001000485b4 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+196>:	mov    0x90(%rbx),%rdi
0x00000001000485bb <_ZN3gnu4java4lang10MainThread9call_mainEJvv+203>:	callq  *0x18(%rbp)
0x00000001000485be <_ZN3gnu4java4lang10MainThread9call_mainEJvv+206>:	callq  0x100062450 <_Z14_Jv_ThreadWaitv>
0x00000001000485c3 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+211>:	lea    0x1629dde(%rip),%rax        # 0x1016723a8 <_ZN4java4lang11ThreadGroup22had_uncaught_exceptionE>
0x00000001000485ca <_ZN3gnu4java4lang10MainThread9call_mainEJvv+218>:	mov    (%rsp),%rbx
0x00000001000485ce <_ZN3gnu4java4lang10MainThread9call_mainEJvv+222>:	mov    0x8(%rsp),%rbp
0x00000001000485d3 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+227>:	mov    0x10(%rsp),%r12
0x00000001000485d8 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+232>:	movzbl (%rax),%edi
0x00000001000485db <_ZN3gnu4java4lang10MainThread9call_mainEJvv+235>:	add    $0x18,%rsp
0x00000001000485df <_ZN3gnu4java4lang10MainThread9call_mainEJvv+239>:	jmpq   0x100409600 <_ZN4java4lang7Runtime20exitNoChecksAccessorEJvi>
0x00000001000485e4 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+244>:	nopw   0x0(%rax,%rax,1)
0x00000001000485ea <_ZN3gnu4java4lang10MainThread9call_mainEJvv+250>:	nopw   0x0(%rax,%rax,1)
0x00000001000485f0 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+256>:	lea    0x94f3c1(%rip),%rdx        # 0x1009979b8 <dyld_stub_write+10530>
0x00000001000485f7 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+263>:	jmpq   0x100048573 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+131>

Do I need to actually stop the process of stepping through the code before I hit
the crash in order to disassemble real_main? I tried...

(gdb) break ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46
Breakpoint 1 at 0x20c49ba4b0a5ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46.
(gdb) r testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar
Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1 testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar
warning: posix_spawn failed, trying execvp, error: 86
Reading symbols for shared libraries +++++.. done
Breakpoint 1 at 0x1000485ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46.

Breakpoint 1, gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46
46	    msg =  "`main' must be public";
(gdb) s
Current language:  auto; currently c++
45	  else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags))
(gdb) s
54	  (*real_main) (args);
(gdb) bt  
#0  gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
#1  0x0000000104875dc0 in ?? () at ClassHelper.java:106
#2  0x0000000104875f00 in ?? () at ClassHelper.java:106
#3  0x000000010493e980 in ?? () at ClassHelper.java:106
#4  0x00000001000b1b74 in _ZN3gnu4java4lang10MainThread3runEJvv (this=0x104875dc0) at MainThread.java:106
Previous frame inner to this frame (gdb could not unwind past this frame)
(gdb) info line 54
Line 54 of "../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc" starts at address 0x1000485b4 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+196> and ends at 0x1000485be <_ZN3gnu4java4lang10MainThread9call_mainEJvv+206>.
(gdb) disassemble 0x1000485b4  0x1000485be
Dump of assembler code from 0x1000485b4 to 0x1000485be:
0x00000001000485b4 <_ZN3gnu4java4lang10MainThread9call_mainEJvv+196>:	mov    0x90(%rbx),%rdi
0x00000001000485bb <_ZN3gnu4java4lang10MainThread9call_mainEJvv+203>:	callq  *0x18(%rbp)
End of assembler dump.
(gdb) 

I'm not sure what to do at this point to disassemble the call destination...

(gdb) disassemble *0x18(%rbp)
A syntax error in expression, near `%rbp)'.
(gdb) disassemble 0x18(%rbp)
A syntax error in expression, near `%rbp)'.
(gdb) disassemble %rbp 
A syntax error in expression, near `%rbp'.

I am at the correct spot though since the next step causes the crash. Also I do
notice that the output from "disassemble 0x1000485b4  0x1000485be" is listed in
the longer disassembly from 0x00000001000485be.
                 Jack

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Jack Howarth wrote:
> On Tue, Dec 01, 2009 at 05:24:29PM +0000, Andrew Haley wrote:
>> Jack Howarth wrote:
>>> On Tue, Dec 01, 2009 at 09:29:36AM +0000, Andrew Haley wrote:
>>>> Jack Howarth wrote:
>>>>
>>>>> (gdb) 
>>>>> 54	  (*real_main) (args);
>>>>> (gdb) 
>>>>>
>>>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>>>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
>>>>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51
>>>>> 51	RowSetEvent.java: No such file or directory.
>>>>> 	in RowSetEvent.java
>>>>> (gdb) 
>>>>>
>>>>> A backtrace only shows...
>>>>>
>>>>> (gdb) bt
>>>>> #0  0x0000000103f05db0 in ?? () at RowSetEvent.java:51
>>>>> #1  0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
>>>>> Previous frame inner to this frame (gdb could not unwind past this frame)
>>>>>
>>>>> Let me know if you have any suggestions for debugging this further.
>>>> Disassemble the first 10 or so instructions at the instruction where the
>>>> EXC_BAD_ACCESS occurs.  I think this is a libffi bug.
>>>>
>>>> Andrew.
>>> Andrew,
>>>    So just to clarify, for the instance of...
>>>
>>> -------------------
>>>
>>> (gdb) 
>>> 0x00000001004168df in _ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258
>>> 258	    return (mod & PUBLIC) != 0;
>>> (gdb) 
>>> gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46
>>> 46	    msg =  "`main' must be public";
>>> (gdb) 
>>> 45	  else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags))
>>> (gdb) 
>>> 54	  (*real_main) (args);
>>> (gdb) 
>>>
>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
>>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51
>>> 51	RowSetEvent.java: No such file or directory.
>>> 	in RowSetEvent.java
>>> (gdb) 
>>>
>>> A backtrace only shows...
>>>
>>> (gdb) bt
>>> #0  0x0000000103f05db0 in ?? () at RowSetEvent.java:51
>>> #1  0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
>>> Previous frame inner to this frame (gdb could not unwind past this frame)
>>>
>>> -----------------
>>>
>>> I want to disassemble from 0x00000001000485be, right?
>> 0x0000000103f05db0, where the fault happens.  I think it's a libffi stub,
>> and I think its page permissions are not correctly set.
>>
>> But let's see.
>>
>> What I would do is, at
>>
>>> 54	  (*real_main) (args);
>> disassemble the call instruction, it's probably  call ($rax)  or somesuch.
>> look in $rax with
>>
>> p $rax
>>
>> and disassemble from the address that's in there.
>>
>> Andrew.
> 
> Andrew,
>    I can't disassemble 0x0000000103f05db0...
> 
> (gdb) disassemble 0x0000000103f05db0
> No function contains specified address.

x/10i 0x0000000103f05db0

Andrew.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Wed, Dec 02, 2009 at 09:34:33AM +0000, Andrew Haley wrote:
> Jack Howarth wrote:
> > On Tue, Dec 01, 2009 at 05:24:29PM +0000, Andrew Haley wrote:
> >> Jack Howarth wrote:
> >>> On Tue, Dec 01, 2009 at 09:29:36AM +0000, Andrew Haley wrote:
> >>>> Jack Howarth wrote:
> >>>>
> >>>>> (gdb) 
> >>>>> 54	  (*real_main) (args);
> >>>>> (gdb) 
> >>>>>
> >>>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
> >>>>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
> >>>>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51
> >>>>> 51	RowSetEvent.java: No such file or directory.
> >>>>> 	in RowSetEvent.java
> >>>>> (gdb) 
> >>>>>
> >>>>> A backtrace only shows...
> >>>>>
> >>>>> (gdb) bt
> >>>>> #0  0x0000000103f05db0 in ?? () at RowSetEvent.java:51
> >>>>> #1  0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
> >>>>> Previous frame inner to this frame (gdb could not unwind past this frame)
> >>>>>
> >>>>> Let me know if you have any suggestions for debugging this further.
> >>>> Disassemble the first 10 or so instructions at the instruction where the
> >>>> EXC_BAD_ACCESS occurs.  I think this is a libffi bug.
> >>>>
> >>>> Andrew.
> >>> Andrew,
> >>>    So just to clarify, for the instance of...
> >>>
> >>> -------------------
> >>>
> >>> (gdb) 
> >>> 0x00000001004168df in _ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258
> >>> 258	    return (mod & PUBLIC) != 0;
> >>> (gdb) 
> >>> gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46
> >>> 46	    msg =  "`main' must be public";
> >>> (gdb) 
> >>> 45	  else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags))
> >>> (gdb) 
> >>> 54	  (*real_main) (args);
> >>> (gdb) 
> >>>
> >>> Program received signal EXC_BAD_ACCESS, Could not access memory.
> >>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
> >>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51
> >>> 51	RowSetEvent.java: No such file or directory.
> >>> 	in RowSetEvent.java
> >>> (gdb) 
> >>>
> >>> A backtrace only shows...
> >>>
> >>> (gdb) bt
> >>> #0  0x0000000103f05db0 in ?? () at RowSetEvent.java:51
> >>> #1  0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
> >>> Previous frame inner to this frame (gdb could not unwind past this frame)
> >>>
> >>> -----------------
> >>>
> >>> I want to disassemble from 0x00000001000485be, right?
> >> 0x0000000103f05db0, where the fault happens.  I think it's a libffi stub,
> >> and I think its page permissions are not correctly set.
> >>
> >> But let's see.
> >>
> >> What I would do is, at
> >>
> >>> 54	  (*real_main) (args);
> >> disassemble the call instruction, it's probably  call ($rax)  or somesuch.
> >> look in $rax with
> >>
> >> p $rax
> >>
> >> and disassemble from the address that's in there.
> >>
> >> Andrew.
> > 
> > Andrew,
> >    I can't disassemble 0x0000000103f05db0...
> > 
> > (gdb) disassemble 0x0000000103f05db0
> > No function contains specified address.
> 
> x/10i 0x0000000103f05db0
> 
> Andrew.

Andrew,
   Okay, I see...

gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1
...
gdb) break ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46
Breakpoint 1 at 0x20c49ba4b0a5ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46.
(gdb) r testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar
Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1 testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar
warning: posix_spawn failed, trying execvp, error: 86
Reading symbols for shared libraries +++++.. done
Breakpoint 1 at 0x1000485ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46.

Breakpoint 1, gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46
46	    msg =  "`main' must be public";
(gdb) s
Current language:  auto; currently c++
45	  else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags))
(gdb) s
54	  (*real_main) (args);
(gdb) x/10i 0x0000000103f05db0
0x103f05db0:	mov    $0x1009814e8,%r11
0x103f05dba:	mov    $0x103f05db0,%r10
0x103f05dc4:	clc    
0x103f05dc5:	rex.WB jmpq   *%r11
0x103f05dc8:	add    %bl,-0x10(%rsi)
0x103f05dcb:	add    (%rcx),%eax
0x103f05dcd:	add    %al,(%rax)
0x103f05dcf:	add    %ah,%al
0x103f05dd1:	(bad)  
0x103f05dd2:	cwtl   
(gdb) bt
#0  gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
#1  0x0000000104875dc0 in ?? () at ClassHelper.java:106
#2  0x0000000104875f00 in ?? () at ClassHelper.java:106
#3  0x000000010493e980 in ?? () at ClassHelper.java:106
#4  0x00000001000b1b74 in _ZN3gnu4java4lang10MainThread3runEJvv (this=0x104875dc0) at MainThread.java:106
Previous frame inner to this frame (gdb could not unwind past this frame)
(gdb) p $rax
$1 = 1

(gdb) s

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
0x0000000103f05db0 in ?? () at ClassHelper.java:106
106	ClassHelper.java: No such file or directory.
	in ClassHelper.java

What do you make of the bad assembly at 0x103f05dd1?
                       Jack

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Jack Howarth wrote:
> On Wed, Dec 02, 2009 at 09:34:33AM +0000, Andrew Haley wrote:
>> Jack Howarth wrote:
>>> On Tue, Dec 01, 2009 at 05:24:29PM +0000, Andrew Haley wrote:
>>>> Jack Howarth wrote:
>>>>> On Tue, Dec 01, 2009 at 09:29:36AM +0000, Andrew Haley wrote:
>>>>>> Jack Howarth wrote:
>>>>>>
>>>>>>> (gdb) 
>>>>>>> 54	  (*real_main) (args);
>>>>>>> (gdb) 
>>>>>>>
>>>>>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>>>>>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
>>>>>>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51
>>>>>>> 51	RowSetEvent.java: No such file or directory.
>>>>>>> 	in RowSetEvent.java
>>>>>>> (gdb) 
>>>>>>>
>>>>>>> A backtrace only shows...
>>>>>>>
>>>>>>> (gdb) bt
>>>>>>> #0  0x0000000103f05db0 in ?? () at RowSetEvent.java:51
>>>>>>> #1  0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
>>>>>>> Previous frame inner to this frame (gdb could not unwind past this frame)
>>>>>>>
>>>>>>> Let me know if you have any suggestions for debugging this further.
>>>>>> Disassemble the first 10 or so instructions at the instruction where the
>>>>>> EXC_BAD_ACCESS occurs.  I think this is a libffi bug.
>>>>>>
>>>>>> Andrew.
>>>>> Andrew,
>>>>>    So just to clarify, for the instance of...
>>>>>
>>>>> -------------------
>>>>>
>>>>> (gdb) 
>>>>> 0x00000001004168df in _ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258
>>>>> 258	    return (mod & PUBLIC) != 0;
>>>>> (gdb) 
>>>>> gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46
>>>>> 46	    msg =  "`main' must be public";
>>>>> (gdb) 
>>>>> 45	  else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags))
>>>>> (gdb) 
>>>>> 54	  (*real_main) (args);
>>>>> (gdb) 
>>>>>
>>>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>>>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
>>>>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51
>>>>> 51	RowSetEvent.java: No such file or directory.
>>>>> 	in RowSetEvent.java
>>>>> (gdb) 
>>>>>
>>>>> A backtrace only shows...
>>>>>
>>>>> (gdb) bt
>>>>> #0  0x0000000103f05db0 in ?? () at RowSetEvent.java:51
>>>>> #1  0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
>>>>> Previous frame inner to this frame (gdb could not unwind past this frame)
>>>>>
>>>>> -----------------
>>>>>
>>>>> I want to disassemble from 0x00000001000485be, right?
>>>> 0x0000000103f05db0, where the fault happens.  I think it's a libffi stub,
>>>> and I think its page permissions are not correctly set.
>>>>
>>>> But let's see.
>>>>
>>>> What I would do is, at
>>>>
>>>>> 54	  (*real_main) (args);
>>>> disassemble the call instruction, it's probably  call ($rax)  or somesuch.
>>>> look in $rax with
>>>>
>>>> p $rax
>>>>
>>>> and disassemble from the address that's in there.
>>>>
>>>> Andrew.
>>> Andrew,
>>>    I can't disassemble 0x0000000103f05db0...
>>>
>>> (gdb) disassemble 0x0000000103f05db0
>>> No function contains specified address.
>> x/10i 0x0000000103f05db0
>>
>> Andrew.
> 
> Andrew,
>    Okay, I see...
> 
> gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1
> ...
> gdb) break ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46
> Breakpoint 1 at 0x20c49ba4b0a5ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46.
> (gdb) r testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar
> Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1 testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar
> warning: posix_spawn failed, trying execvp, error: 86
> Reading symbols for shared libraries +++++.. done
> Breakpoint 1 at 0x1000485ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46.
> 
> Breakpoint 1, gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46
> 46	    msg =  "`main' must be public";
> (gdb) s
> Current language:  auto; currently c++
> 45	  else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags))
> (gdb) s
> 54	  (*real_main) (args);
> (gdb) x/10i 0x0000000103f05db0
> 0x103f05db0:	mov    $0x1009814e8,%r11
> 0x103f05dba:	mov    $0x103f05db0,%r10
> 0x103f05dc4:	clc    
> 0x103f05dc5:	rex.WB jmpq   *%r11
> 0x103f05dc8:	add    %bl,-0x10(%rsi)
> 0x103f05dcb:	add    (%rcx),%eax
> 0x103f05dcd:	add    %al,(%rax)
> 0x103f05dcf:	add    %ah,%al
> 0x103f05dd1:	(bad)  
> 0x103f05dd2:	cwtl   
> (gdb) bt
> #0  gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
> #1  0x0000000104875dc0 in ?? () at ClassHelper.java:106
> #2  0x0000000104875f00 in ?? () at ClassHelper.java:106
> #3  0x000000010493e980 in ?? () at ClassHelper.java:106
> #4  0x00000001000b1b74 in _ZN3gnu4java4lang10MainThread3runEJvv (this=0x104875dc0) at MainThread.java:106
> Previous frame inner to this frame (gdb could not unwind past this frame)
> (gdb) p $rax
> $1 = 1
> 
> (gdb) s
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
> 0x0000000103f05db0 in ?? () at ClassHelper.java:106
> 106	ClassHelper.java: No such file or directory.
> 	in ClassHelper.java
> 
> What do you make of the bad assembly at 0x103f05dd1?

There is no bad assembly: there's a jump at 0x103f05dc5.

I know what's going on.

The OS forbids execution of memory in the heap.  But, there is an extra
flag, -Wl,-allow_stack_execute, that allows this permission.  This is
a misnamed flag, since we never execute code on the stack.  I think it's
really controlling heap execution, not stack execution.

We need to pass this flag everywhere, whenever a program is compiled by
gcj.

Andrew.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Thu, Dec 03, 2009 at 10:25:30AM +0000, Andrew Haley wrote:
> Jack Howarth wrote:
> > On Wed, Dec 02, 2009 at 09:34:33AM +0000, Andrew Haley wrote:
> >> Jack Howarth wrote:
> >>> On Tue, Dec 01, 2009 at 05:24:29PM +0000, Andrew Haley wrote:
> >>>> Jack Howarth wrote:
> >>>>> On Tue, Dec 01, 2009 at 09:29:36AM +0000, Andrew Haley wrote:
> >>>>>> Jack Howarth wrote:
> >>>>>>
> >>>>>>> (gdb) 
> >>>>>>> 54	  (*real_main) (args);
> >>>>>>> (gdb) 
> >>>>>>>
> >>>>>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
> >>>>>>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
> >>>>>>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51
> >>>>>>> 51	RowSetEvent.java: No such file or directory.
> >>>>>>> 	in RowSetEvent.java
> >>>>>>> (gdb) 
> >>>>>>>
> >>>>>>> A backtrace only shows...
> >>>>>>>
> >>>>>>> (gdb) bt
> >>>>>>> #0  0x0000000103f05db0 in ?? () at RowSetEvent.java:51
> >>>>>>> #1  0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
> >>>>>>> Previous frame inner to this frame (gdb could not unwind past this frame)
> >>>>>>>
> >>>>>>> Let me know if you have any suggestions for debugging this further.
> >>>>>> Disassemble the first 10 or so instructions at the instruction where the
> >>>>>> EXC_BAD_ACCESS occurs.  I think this is a libffi bug.
> >>>>>>
> >>>>>> Andrew.
> >>>>> Andrew,
> >>>>>    So just to clarify, for the instance of...
> >>>>>
> >>>>> -------------------
> >>>>>
> >>>>> (gdb) 
> >>>>> 0x00000001004168df in _ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258
> >>>>> 258	    return (mod & PUBLIC) != 0;
> >>>>> (gdb) 
> >>>>> gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46
> >>>>> 46	    msg =  "`main' must be public";
> >>>>> (gdb) 
> >>>>> 45	  else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags))
> >>>>> (gdb) 
> >>>>> 54	  (*real_main) (args);
> >>>>> (gdb) 
> >>>>>
> >>>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
> >>>>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
> >>>>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51
> >>>>> 51	RowSetEvent.java: No such file or directory.
> >>>>> 	in RowSetEvent.java
> >>>>> (gdb) 
> >>>>>
> >>>>> A backtrace only shows...
> >>>>>
> >>>>> (gdb) bt
> >>>>> #0  0x0000000103f05db0 in ?? () at RowSetEvent.java:51
> >>>>> #1  0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
> >>>>> Previous frame inner to this frame (gdb could not unwind past this frame)
> >>>>>
> >>>>> -----------------
> >>>>>
> >>>>> I want to disassemble from 0x00000001000485be, right?
> >>>> 0x0000000103f05db0, where the fault happens.  I think it's a libffi stub,
> >>>> and I think its page permissions are not correctly set.
> >>>>
> >>>> But let's see.
> >>>>
> >>>> What I would do is, at
> >>>>
> >>>>> 54	  (*real_main) (args);
> >>>> disassemble the call instruction, it's probably  call ($rax)  or somesuch.
> >>>> look in $rax with
> >>>>
> >>>> p $rax
> >>>>
> >>>> and disassemble from the address that's in there.
> >>>>
> >>>> Andrew.
> >>> Andrew,
> >>>    I can't disassemble 0x0000000103f05db0...
> >>>
> >>> (gdb) disassemble 0x0000000103f05db0
> >>> No function contains specified address.
> >> x/10i 0x0000000103f05db0
> >>
> >> Andrew.
> > 
> > Andrew,
> >    Okay, I see...
> > 
> > gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1
> > ...
> > gdb) break ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46
> > Breakpoint 1 at 0x20c49ba4b0a5ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46.
> > (gdb) r testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar
> > Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1 testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar
> > warning: posix_spawn failed, trying execvp, error: 86
> > Reading symbols for shared libraries +++++.. done
> > Breakpoint 1 at 0x1000485ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46.
> > 
> > Breakpoint 1, gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46
> > 46	    msg =  "`main' must be public";
> > (gdb) s
> > Current language:  auto; currently c++
> > 45	  else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags))
> > (gdb) s
> > 54	  (*real_main) (args);
> > (gdb) x/10i 0x0000000103f05db0
> > 0x103f05db0:	mov    $0x1009814e8,%r11
> > 0x103f05dba:	mov    $0x103f05db0,%r10
> > 0x103f05dc4:	clc    
> > 0x103f05dc5:	rex.WB jmpq   *%r11
> > 0x103f05dc8:	add    %bl,-0x10(%rsi)
> > 0x103f05dcb:	add    (%rcx),%eax
> > 0x103f05dcd:	add    %al,(%rax)
> > 0x103f05dcf:	add    %ah,%al
> > 0x103f05dd1:	(bad)  
> > 0x103f05dd2:	cwtl   
> > (gdb) bt
> > #0  gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
> > #1  0x0000000104875dc0 in ?? () at ClassHelper.java:106
> > #2  0x0000000104875f00 in ?? () at ClassHelper.java:106
> > #3  0x000000010493e980 in ?? () at ClassHelper.java:106
> > #4  0x00000001000b1b74 in _ZN3gnu4java4lang10MainThread3runEJvv (this=0x104875dc0) at MainThread.java:106
> > Previous frame inner to this frame (gdb could not unwind past this frame)
> > (gdb) p $rax
> > $1 = 1
> > 
> > (gdb) s
> > 
> > Program received signal EXC_BAD_ACCESS, Could not access memory.
> > Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
> > 0x0000000103f05db0 in ?? () at ClassHelper.java:106
> > 106	ClassHelper.java: No such file or directory.
> > 	in ClassHelper.java
> > 
> > What do you make of the bad assembly at 0x103f05dd1?
> 
> There is no bad assembly: there's a jump at 0x103f05dc5.
> 
> I know what's going on.
> 
> The OS forbids execution of memory in the heap.  But, there is an extra
> flag, -Wl,-allow_stack_execute, that allows this permission.  This is
> a misnamed flag, since we never execute code on the stack.  I think it's
> really controlling heap execution, not stack execution.
> 
> We need to pass this flag everywhere, whenever a program is compiled by
> gcj.
> 
> Andrew.

Andrew,
   This sounds like the patch that Andreas proposed in...

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

which didn't solve the problem on my MacPro or MacBook Pro
under darwin9 or darwin10. He also ran into the issue again
later...

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

Do you think that  -Wl,-allow_stack_execute needs to be passed
even more widely than on just ecjx_LDFLAGS? Any suggestions as
to where I should be passing it? Perhaps on something like
LIBJAVA_LDFLAGS_NOUNDEF at the toplevel of libjava? Or should
we even be building libffi and boehm-gc with that as well?
                     Jack

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Jack Howarth wrote:
> On Thu, Dec 03, 2009 at 10:25:30AM +0000, Andrew Haley wrote:
>> Jack Howarth wrote:
>>> On Wed, Dec 02, 2009 at 09:34:33AM +0000, Andrew Haley wrote:
>>>> Jack Howarth wrote:
>>>>> On Tue, Dec 01, 2009 at 05:24:29PM +0000, Andrew Haley wrote:
>>>>>> Jack Howarth wrote:
>>>>>>> On Tue, Dec 01, 2009 at 09:29:36AM +0000, Andrew Haley wrote:

>>>
>>> What do you make of the bad assembly at 0x103f05dd1?
>> There is no bad assembly: there's a jump at 0x103f05dc5.
>>
>> I know what's going on.
>>
>> The OS forbids execution of memory in the heap.  But, there is an extra
>> flag, -Wl,-allow_stack_execute, that allows this permission.  This is
>> a misnamed flag, since we never execute code on the stack.  I think it's
>> really controlling heap execution, not stack execution.
>>
>> We need to pass this flag everywhere, whenever a program is compiled by
>> gcj.
>>
>> Andrew.
> 
> Andrew,
>    This sounds like the patch that Andreas proposed in...
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3
> 
> which didn't solve the problem on my MacPro or MacBook Pro
> under darwin9 or darwin10. He also ran into the issue again
> later...
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c17
> 
> Do you think that  -Wl,-allow_stack_execute needs to be passed
> even more widely than on just ecjx_LDFLAGS? Any suggestions as
> to where I should be passing it? Perhaps on something like
> LIBJAVA_LDFLAGS_NOUNDEF at the toplevel of libjava? Or should
> we even be building libffi and boehm-gc with that as well?

I don't see =-Wl,-allow_stack_execute passed to anything except
when linking gij.  That's why IMO gij works but nothing else does.

This needs to be everywhere, for all programs.  I think SYSTEMSPEC
would do it, or add a new linker configure variable.

Andrew.

RE: [patch] Fix oddity in personality routine

[Boehm, Hans]

> From:  Jack Howarth
> Do you think that  -Wl,-allow_stack_execute needs to be 
> passed even more widely than on just ecjx_LDFLAGS? Any 
> suggestions as to where I should be passing it? Perhaps on 
> something like LIBJAVA_LDFLAGS_NOUNDEF at the toplevel of 
> libjava? Or should we even be building libffi and boehm-gc 
> with that as well?
>                      Jack
> 
> 
I haven't been following this completely, but:

The GC also has a compile-time flag NO_EXECUTE_PERMISSION, which affects heap executability.  I think the documentation says that this only affects incremental collection, but looking at the code, I'm not sure I believe that anymore.  I think it generally affects whether memory allocated with mmap is made executable, and we've been doing more and more of that.

Hans

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Boehm, Hans wrote:
>> From:  Jack Howarth
>> Do you think that  -Wl,-allow_stack_execute needs to be 
>> passed even more widely than on just ecjx_LDFLAGS? Any 
>> suggestions as to where I should be passing it? Perhaps on 
>> something like LIBJAVA_LDFLAGS_NOUNDEF at the toplevel of 
>> libjava? Or should we even be building libffi and boehm-gc 
>> with that as well?
>>
> I haven't been following this completely, but:
> 
> The GC also has a compile-time flag NO_EXECUTE_PERMISSION, which affects heap executability.

I think that's probably not the cause, since libffi allocates memory itself.

Andrew.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Thu, Dec 03, 2009 at 09:25:11PM +0000, Andrew Haley wrote:
> Boehm, Hans wrote:
> >> From:  Jack Howarth
> >> Do you think that  -Wl,-allow_stack_execute needs to be 
> >> passed even more widely than on just ecjx_LDFLAGS? Any 
> >> suggestions as to where I should be passing it? Perhaps on 
> >> something like LIBJAVA_LDFLAGS_NOUNDEF at the toplevel of 
> >> libjava? Or should we even be building libffi and boehm-gc 
> >> with that as well?
> >>
> > I haven't been following this completely, but:
> > 
> > The GC also has a compile-time flag NO_EXECUTE_PERMISSION, which affects heap executability.
> 
> I think that's probably not the cause, since libffi allocates memory itself.
> 
> Andrew.

Andrew,
   On reflection, shouldn't something like...

Index: libjava/Makefile.in
===================================================================
--- libjava/Makefile.in	(revision 154965)
+++ libjava/Makefile.in	(working copy)
@@ -8500,8 +8500,7 @@
 	$(am__append_28)
 gij_SOURCES = 
 gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \
-	-shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \
-	$(extra_gij_ldflags) 
+	-shared-libgcc $(THREADLDFLAGS) $(extra_ldflags)
 
 gij_LINK = $(GCJLINK) $(gij_LDFLAGS)
 gij_LDADD = -L$(here)/.libs libgij.la
Index: libjava/Makefile.am
===================================================================
--- libjava/Makefile.am	(revision 154965)
+++ libjava/Makefile.am	(working copy)
@@ -294,7 +294,7 @@
 
 LTLDFLAGS = $(shell $(top_srcdir)/../libtool-ldflags $(LDFLAGS))
 GCJLINK = $(LIBTOOL) --tag=GCJ $(LIBTOOLFLAGS) --mode=link $(GCJ) -L$(here) \
-	  $(JC1FLAGS) $(LTLDFLAGS) -o $@
+	   $(extra_gij_ldflags) $(JC1FLAGS) $(LTLDFLAGS) -o $@
 GCJ_FOR_ECJX = @GCJ_FOR_ECJX@
 GCJ_FOR_ECJX_LINK = $(GCJ_FOR_ECJX) -o $@
 LIBLINK = $(LIBTOOL) --tag=CXX $(LIBTOOLFLAGS) --mode=link $(CXX) -L$(here) \
@@ -1065,8 +1065,7 @@
 ## need this because we are explicitly using libtool to link using the
 ## `.la' file.
 gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \
-	-shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \
-	$(extra_gij_ldflags) 
+	-shared-libgcc $(THREADLDFLAGS) $(extra_ldflags)
 gij_LINK = $(GCJLINK) $(gij_LDFLAGS)
 ## See jv_convert_LDADD.
 gij_LDADD = -L$(here)/.libs libgij.la

...be appropriate to make sure that all java executables on darwin are linked with
-Wl,-allow_stack_execute? However, this raises the question of why the gcj and ecj1
compilers aren't doing the same? As I understand this, any executables created
with libraries containing code that executes on the stack (like libgcj) needs
to link the binaries with -Wl,-allow_stack_execute. Shouldn't this apply to
gcj and ecj1 as well since they create executables which are linked against
libgcj? Wouldn't we have to do this by adding the missing -allow_stack_execute flag
to libjava/libgcj.spec.in?
            Jack

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

Using the patch...

Index: libjava/Makefile.in
===================================================================
--- libjava/Makefile.in	(revision 154965)
+++ libjava/Makefile.in	(working copy)
@@ -1070,7 +1070,7 @@
 GCJ_WITH_FLAGS = $(GCJ) --encoding=UTF-8 -Wno-deprecated
 LTLDFLAGS = $(shell $(top_srcdir)/../libtool-ldflags $(LDFLAGS))
 GCJLINK = $(LIBTOOL) --tag=GCJ $(LIBTOOLFLAGS) --mode=link $(GCJ) -L$(here) \
-	  $(JC1FLAGS) $(LTLDFLAGS) -o $@
+	 $(extra_gij_ldflags) $(JC1FLAGS) $(LTLDFLAGS) -o $@
 
 GCJ_FOR_ECJX_LINK = $(GCJ_FOR_ECJX) -o $@
 LIBLINK = $(LIBTOOL) --tag=CXX $(LIBTOOLFLAGS) --mode=link $(CXX) -L$(here) \
@@ -8500,8 +8500,7 @@
 	$(am__append_28)
 gij_SOURCES = 
 gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \
-	-shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \
-	$(extra_gij_ldflags) 
+	-shared-libgcc $(THREADLDFLAGS) $(extra_ldflags)
 
 gij_LINK = $(GCJLINK) $(gij_LDFLAGS)
 gij_LDADD = -L$(here)/.libs libgij.la
Index: libjava/Makefile.am
===================================================================
--- libjava/Makefile.am	(revision 154965)
+++ libjava/Makefile.am	(working copy)
@@ -294,7 +294,7 @@
 
 LTLDFLAGS = $(shell $(top_srcdir)/../libtool-ldflags $(LDFLAGS))
 GCJLINK = $(LIBTOOL) --tag=GCJ $(LIBTOOLFLAGS) --mode=link $(GCJ) -L$(here) \
-	  $(JC1FLAGS) $(LTLDFLAGS) -o $@
+	   $(extra_gij_ldflags) $(JC1FLAGS) $(LTLDFLAGS) -o $@
 GCJ_FOR_ECJX = @GCJ_FOR_ECJX@
 GCJ_FOR_ECJX_LINK = $(GCJ_FOR_ECJX) -o $@
 LIBLINK = $(LIBTOOL) --tag=CXX $(LIBTOOLFLAGS) --mode=link $(CXX) -L$(here) \
@@ -1065,8 +1065,7 @@
 ## need this because we are explicitly using libtool to link using the
 ## `.la' file.
 gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \
-	-shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \
-	$(extra_gij_ldflags) 
+	-shared-libgcc $(THREADLDFLAGS) $(extra_ldflags)
 gij_LINK = $(GCJLINK) $(gij_LDFLAGS)
 ## See jv_convert_LDADD.
 gij_LDADD = -L$(here)/.libs libgij.la

The crash in gcj still occurs but it may have moved location (I am under darwin10
at the moment). I see...

gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/ecj1
(gdb) r testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/share/xtal/ccp4-6.1.2/bin/:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc3tiRxo.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccsmjxPB.jar
Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/ecj1 testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/share/xtal/ccp4-6.1.2/bin/:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc3tiRxo.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccsmjxPB.jar
Reading symbols for shared libraries +++++. done

Program received signal SIGABRT, Aborted.
0x00007fff843d4fe6 in __kill ()
(gdb) bt
#0  0x00007fff843d4fe6 in __kill ()
#1  0x00007fff84475e32 in abort ()
#2  0x00007fff844bffc9 in _Unwind_FindEnclosingFunction ()
#3  0x000000010001091c in gnu::classpath::VMStackWalker::getCallingClassLoader (pc=0x10098c8ac) at ../../../gcc-4.5-20091203/libjava/gnu/classpath/natVMStackWalker.cc:104
Previous frame inner to this frame (gdb could not unwind past this frame)
(gdb) x/10i 0x000000010001091c
0x10001091c <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+28>:	mov    %rax,%rbx
0x10001091f <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+31>:	callq  0x100005cd0 <_ZN14_Jv_StackTrace14UpdateNCodeMapEv>
0x100010924 <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+36>:	lea    0x1c7b4b5(%rip),%rax        # 0x101c8bde0 <_ZN14_Jv_StackTrace8ncodeMapE>
0x10001092b <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+43>:	mov    %rbx,%rsi
0x10001092e <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+46>:	mov    (%rax),%rdi
0x100010931 <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+49>:	mov    (%rdi),%rdx
0x100010934 <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+52>:	callq  *0x60(%rdx)
0x100010937 <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+55>:	test   %rax,%rax
0x10001093a <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+58>:	je     0x100010950 <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+80>
0x10001093c <_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+60>:	mov    0xa8(%rax),%rax

This is interesting since on x86_64-apple-darwin10, we have been failing...

FAIL: WalkerTest execution - source compiled test
FAIL: WalkerTest -findirect-dispatch execution - source compiled test
FAIL: WalkerTest -O3 execution - source compiled test
FAIL: WalkerTest -O3 -findirect-dispatch execution - source compiled test

in the libjava testsuite.
           Jack

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Jack Howarth wrote:
> Using the patch...

Let's see the compile time output, when the executables were linked.

> This is interesting since on x86_64-apple-darwin10, we have been failing...
> 
> FAIL: WalkerTest execution - source compiled test
> FAIL: WalkerTest -findirect-dispatch execution - source compiled test
> FAIL: WalkerTest -O3 execution - source compiled test
> FAIL: WalkerTest -O3 -findirect-dispatch execution - source compiled test

Since when?  You didn't mention this before.

Andrew.

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Jack Howarth wrote:
> On Thu, Dec 03, 2009 at 09:25:11PM +0000, Andrew Haley wrote:
>> Boehm, Hans wrote:
>>>> From:  Jack Howarth
>>>> Do you think that  -Wl,-allow_stack_execute needs to be 
>>>> passed even more widely than on just ecjx_LDFLAGS? Any 
>>>> suggestions as to where I should be passing it? Perhaps on 
>>>> something like LIBJAVA_LDFLAGS_NOUNDEF at the toplevel of 
>>>> libjava? Or should we even be building libffi and boehm-gc 
>>>> with that as well?
>>>>
>>> I haven't been following this completely, but:
>>>
>>> The GC also has a compile-time flag NO_EXECUTE_PERMISSION, which affects heap executability.
>> I think that's probably not the cause, since libffi allocates memory itself.
>>
>> Andrew.
> 
> Andrew,
>    On reflection, shouldn't something like...
> 
> Index: libjava/Makefile.in
> ===================================================================
> --- libjava/Makefile.in	(revision 154965)
> +++ libjava/Makefile.in	(working copy)
> @@ -8500,8 +8500,7 @@
>  	$(am__append_28)
>  gij_SOURCES = 
>  gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \
> -	-shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \
> -	$(extra_gij_ldflags) 
> +	-shared-libgcc $(THREADLDFLAGS) $(extra_ldflags)
>  
>  gij_LINK = $(GCJLINK) $(gij_LDFLAGS)
>  gij_LDADD = -L$(here)/.libs libgij.la
> Index: libjava/Makefile.am
> ===================================================================
> --- libjava/Makefile.am	(revision 154965)
> +++ libjava/Makefile.am	(working copy)
> @@ -294,7 +294,7 @@
>  
>  LTLDFLAGS = $(shell $(top_srcdir)/../libtool-ldflags $(LDFLAGS))
>  GCJLINK = $(LIBTOOL) --tag=GCJ $(LIBTOOLFLAGS) --mode=link $(GCJ) -L$(here) \
> -	  $(JC1FLAGS) $(LTLDFLAGS) -o $@
> +	   $(extra_gij_ldflags) $(JC1FLAGS) $(LTLDFLAGS) -o $@
>  GCJ_FOR_ECJX = @GCJ_FOR_ECJX@
>  GCJ_FOR_ECJX_LINK = $(GCJ_FOR_ECJX) -o $@
>  LIBLINK = $(LIBTOOL) --tag=CXX $(LIBTOOLFLAGS) --mode=link $(CXX) -L$(here) \
> @@ -1065,8 +1065,7 @@
>  ## need this because we are explicitly using libtool to link using the
>  ## `.la' file.
>  gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \
> -	-shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \
> -	$(extra_gij_ldflags) 
> +	-shared-libgcc $(THREADLDFLAGS) $(extra_ldflags)
>  gij_LINK = $(GCJLINK) $(gij_LDFLAGS)
>  ## See jv_convert_LDADD.
>  gij_LDADD = -L$(here)/.libs libgij.la
> 
> ...be appropriate to make sure that all java executables on darwin are linked with
> -Wl,-allow_stack_execute?

No, because it will only affect the binaries in gcj, not things the
user compiles.  That's why I suggested SYSTEMSPEC.

Andrew.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Fri, Dec 04, 2009 at 09:44:29AM +0000, Andrew Haley wrote:
> Jack Howarth wrote:
> > Using the patch...
> 
> Let's see the compile time output, when the executables were linked.
> 
> > This is interesting since on x86_64-apple-darwin10, we have been failing...
> > 
> > FAIL: WalkerTest execution - source compiled test
> > FAIL: WalkerTest -findirect-dispatch execution - source compiled test
> > FAIL: WalkerTest -O3 execution - source compiled test
> > FAIL: WalkerTest -O3 -findirect-dispatch execution - source compiled test
> 
> Since when?  You didn't mention this before.
> 
> Andrew.

Andrew,
    I believe we have been seeing the additional WalkerTest
failures under darwin10 ever since gcc trunk was fixed so
that darwin10 built with stack execution like darwin9...

http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01532.html

However this may all be a red herring because x86_64-apple-darwin9
(which doesn't show these WalkerTest failures) shows the
same issue with gcj crashing when compiling java code.
     I suspect we may have a layered problem here and need
to work through each section. This weekend, I do some additional
builds to verify that the crash debugs to the same locations
in both darwin9 and darwin10 with and without the proposed
patch to pass -Wl,-allow_stack_execute on GCJLINK. 
     The WalkerTest failures in darwin10 may be orthogonal to
the issue of gcj crashing since they don't occur in darwin9
and darwin9 has the gcj issue as well. I'll do some builds this
weekend to verify that...

1) x86_64-apple-darwin9 still passes the WalkerTests
2) x86_64-apple-darwin9 and x86_64-apple-darwin10 both backtrace
to the same place when gcj crashes compiling java code.
3) When the GCJLINK to patched to always pass -Wl,-allow_stack_execute
that the backtrace moves to the same place in both x86_64-apple-darwin9
and x86_64-apple-darwin10.
4) I'll also back out the libgcc-ext patch completely and verify that
x86_64-apple-darwin9 crashes at the same locations for step 2 and 3.
This will verify that the system unwinder and the FSF libgcc unwinder
both behave the same in these gcj crashes.
                Jack
ps As I mentioned before, darwin10 uses an unwinder in libSystem which
is derived from that in gcc 4.2.1. Also, since the libgcc_ext patch
went into gcc trunk, darwin9 also links in the system libgcc_s.10.5
before the FSF libgcc_s so that it also now uses the system unwinder
(from libgcc). However note that thse gcj crashes predate all of this.
I have verified that they go as far back as gcc 4.3.4.

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Jack Howarth wrote:
> On Fri, Dec 04, 2009 at 09:44:29AM +0000, Andrew Haley wrote:
>> Jack Howarth wrote:
>>> Using the patch...
>> Let's see the compile time output, when the executables were linked.
>>
>>> This is interesting since on x86_64-apple-darwin10, we have been failing...
>>>
>>> FAIL: WalkerTest execution - source compiled test
>>> FAIL: WalkerTest -findirect-dispatch execution - source compiled test
>>> FAIL: WalkerTest -O3 execution - source compiled test
>>> FAIL: WalkerTest -O3 -findirect-dispatch execution - source compiled test
>> Since when?  You didn't mention this before.

>     I believe we have been seeing the additional WalkerTest
> failures under darwin10 ever since gcc trunk was fixed so
> that darwin10 built with stack execution like darwin9...
> 
> http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01532.html

OK.  I'm pretty sure this is a different failure.

> However this may all be a red herring because x86_64-apple-darwin9
> (which doesn't show these WalkerTest failures) shows the
> same issue with gcj crashing when compiling java code.
>      I suspect we may have a layered problem here and need
> to work through each section. This weekend, I do some additional
> builds to verify that the crash debugs to the same locations
> in both darwin9 and darwin10 with and without the proposed
> patch to pass -Wl,-allow_stack_execute on GCJLINK.

Right.

>      The WalkerTest failures in darwin10 may be orthogonal to
> the issue of gcj crashing since they don't occur in darwin9
> and darwin9 has the gcj issue as well. I'll do some builds this
> weekend to verify that...
> 
> 1) x86_64-apple-darwin9 still passes the WalkerTests
> 2) x86_64-apple-darwin9 and x86_64-apple-darwin10 both backtrace
> to the same place when gcj crashes compiling java code.
> 3) When the GCJLINK to patched to always pass -Wl,-allow_stack_execute
> that the backtrace moves to the same place in both x86_64-apple-darwin9
> and x86_64-apple-darwin10.

Do you see the same page fault once -Wl,-allow_stack_execute is used?
If not, this one is fixed, and we can look at the unwinder fproblem.

> 4) I'll also back out the libgcc-ext patch completely and verify that
> x86_64-apple-darwin9 crashes at the same locations for step 2 and 3.
> This will verify that the system unwinder and the FSF libgcc unwinder
> both behave the same in these gcj crashes.

> ps As I mentioned before, darwin10 uses an unwinder in libSystem which
> is derived from that in gcc 4.2.1. Also, since the libgcc_ext patch
> went into gcc trunk, darwin9 also links in the system libgcc_s.10.5
> before the FSF libgcc_s so that it also now uses the system unwinder
> (from libgcc). However note that thse gcj crashes predate all of this.
> I have verified that they go as far back as gcc 4.3.4.

OK.  So, we may have just one bug left rather than two.  Here's hoping.

Andrew.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Fri, Dec 04, 2009 at 02:59:43PM +0000, Andrew Haley wrote:
> 
> >      I suspect we may have a layered problem here and need
> > to work through each section. This weekend, I do some additional
> > builds to verify that the crash debugs to the same locations
> > in both darwin9 and darwin10 with and without the proposed
> > patch to pass -Wl,-allow_stack_execute on GCJLINK.
> 
> Right.
> 

Andrew,
   Just to double check, you do agree that everything linked with 
GCJLINK should be passed -Wl,-allow_stack_execute on darwin9/darwin10?
I am a bit confused by the criteria used to determine which java binaries
need the ld flag for -allow_stack_execute. If the a shared library contains
code that needs to execute on the stack (libgcj) shouldn't any executable
that links in that shared lib use the -allow_stack_execute ld flag?
                Jack

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Jack Howarth wrote:
> On Fri, Dec 04, 2009 at 02:59:43PM +0000, Andrew Haley wrote:
>>>      I suspect we may have a layered problem here and need
>>> to work through each section. This weekend, I do some additional
>>> builds to verify that the crash debugs to the same locations
>>> in both darwin9 and darwin10 with and without the proposed
>>> patch to pass -Wl,-allow_stack_execute on GCJLINK.
>> Right.
>>
> 
> Andrew,
>    Just to double check, you do agree that everything linked with 
> GCJLINK should be passed -Wl,-allow_stack_execute on darwin9/darwin10?

I think so.

> I am a bit confused by the criteria used to determine which java binaries
> need the ld flag for -allow_stack_execute. If the a shared library contains
> code that needs to execute on the stack

No gcj library needs to execute on the stack, only the heap.  I think the flag
is misnamed.

> (libgcj) shouldn't any executable
> that links in that shared lib use the -allow_stack_execute ld flag?

Yes, which is why I suggested you use SYSTEMSPEC.  (Twice now, I think.  :-)

SYSTEMSPEC should pass that flag to everything liked with gcj.

Andrew.

Re: [patch] Fix oddity in personality routine

[Bryce McKinlay]

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]

On Fri, Dec 4, 2009 at 3:48 PM, Andrew Haley <aph@redhat.com> wrote:

> Yes, which is why I suggested you use SYSTEMSPEC.  (Twice now, I think.  :-)
>
> SYSTEMSPEC should pass that flag to everything liked with gcj.

Jack,

Here's a patch that adds the allow_stack_execute flag to SYSTEMSPEC as
suggested by Andrew.

It does not fix the problem with ecj, but I agree it's a good idea.

Bryce

[-- Attachment #2: libgcj-darwin-systemspec.patch --]
[-- Type: application/octet-stream, Size: 11812 bytes --]

Index: Makefile.in
===================================================================
--- Makefile.in	(revision 154954)
+++ Makefile.in	(working copy)
@@ -819,7 +819,6 @@
 docdir = @docdir@
 dvidir = @dvidir@
 exec_prefix = @exec_prefix@
-extra_gij_ldflags = @extra_gij_ldflags@
 extra_ldflags = @extra_ldflags@
 extra_ldflags_libjava = @extra_ldflags_libjava@ $(am__append_9)
 gcc_suffix = @gcc_suffix@
@@ -8500,8 +8499,7 @@
 	$(am__append_28)
 gij_SOURCES = 
 gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \
-	-shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \
-	$(extra_gij_ldflags) 
+	-shared-libgcc $(THREADLDFLAGS) $(extra_ldflags)
 
 gij_LINK = $(GCJLINK) $(gij_LDFLAGS)
 gij_LDADD = -L$(here)/.libs libgij.la
Index: configure.ac
===================================================================
--- configure.ac	(revision 154954)
+++ configure.ac	(working copy)
@@ -889,6 +889,9 @@
         SYSTEMSPEC="-lunicows $SYSTEMSPEC"
       fi
     ;;
+    *-*-darwin[[912]]*)
+      SYSTEMSPEC="-allow_stack_execute"
+    ;;
     *)
       SYSTEMSPEC=
     ;;
@@ -919,9 +922,6 @@
     # on Darwin -single_module speeds up loading of the dynamic libraries.
     extra_ldflags_libjava=-Wl,-single_module
     ;;
-*-*-darwin[[912]]*)
-    extra_gij_ldflags=-Wl,-allow_stack_execute
-    ;;
 arm*linux*eabi)
     # Some of the ARM unwinder code is actually in libstdc++.  We
     # could in principle replicate it in libgcj, but it's better to
@@ -935,7 +935,6 @@
     ;;
 esac
 AC_SUBST(extra_ldflags_libjava)
-AC_SUBST(extra_gij_ldflags)
 AC_SUBST(extra_ldflags)
 AC_SUBST(LIBSTDCXXSPEC)
 
Index: configure
===================================================================
--- configure	(revision 154954)
+++ configure	(working copy)
@@ -843,7 +843,6 @@
 LIBGCJTESTSPEC
 LIBSTDCXXSPEC
 extra_ldflags
-extra_gij_ldflags
 extra_ldflags_libjava
 X_EXTRA_LIBS
 X_LIBS
@@ -7511,13 +7510,13 @@
 else
   lt_cv_nm_interface="BSD nm"
   echo "int some_variable = 0;" > conftest.$ac_ext
-  (eval echo "\"\$as_me:7514: $ac_compile\"" >&5)
+  (eval echo "\"\$as_me:7513: $ac_compile\"" >&5)
   (eval "$ac_compile" 2>conftest.err)
   cat conftest.err >&5
-  (eval echo "\"\$as_me:7517: $NM \\\"conftest.$ac_objext\\\"\"" >&5)
+  (eval echo "\"\$as_me:7516: $NM \\\"conftest.$ac_objext\\\"\"" >&5)
   (eval "$NM \"conftest.$ac_objext\"" 2>conftest.err > conftest.out)
   cat conftest.err >&5
-  (eval echo "\"\$as_me:7520: output\"" >&5)
+  (eval echo "\"\$as_me:7519: output\"" >&5)
   cat conftest.out >&5
   if $GREP 'External.*some_variable' conftest.out > /dev/null; then
     lt_cv_nm_interface="MS dumpbin"
@@ -8712,7 +8711,7 @@
   ;;
 *-*-irix6*)
   # Find out which ABI we are using.
-  echo '#line 8715 "configure"' > conftest.$ac_ext
+  echo '#line 8714 "configure"' > conftest.$ac_ext
   if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_compile\""; } >&5
   (eval $ac_compile) 2>&5
   ac_status=$?
@@ -10646,11 +10645,11 @@
    -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:10649: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:10648: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:10653: \$? = $ac_status" >&5
+   echo "$as_me:10652: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings other than the usual output.
@@ -10985,11 +10984,11 @@
    -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:10988: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:10987: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:10992: \$? = $ac_status" >&5
+   echo "$as_me:10991: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings other than the usual output.
@@ -11090,11 +11089,11 @@
    -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:11093: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:11092: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>out/conftest.err)
    ac_status=$?
    cat out/conftest.err >&5
-   echo "$as_me:11097: \$? = $ac_status" >&5
+   echo "$as_me:11096: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s out/conftest2.$ac_objext
    then
      # The compiler can only warn and ignore the option if not recognized
@@ -11145,11 +11144,11 @@
    -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:11148: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:11147: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>out/conftest.err)
    ac_status=$?
    cat out/conftest.err >&5
-   echo "$as_me:11152: \$? = $ac_status" >&5
+   echo "$as_me:11151: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s out/conftest2.$ac_objext
    then
      # The compiler can only warn and ignore the option if not recognized
@@ -13554,7 +13553,7 @@
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 13557 "configure"
+#line 13556 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -13650,7 +13649,7 @@
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 13653 "configure"
+#line 13652 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -15612,11 +15611,11 @@
    -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:15615: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:15614: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:15619: \$? = $ac_status" >&5
+   echo "$as_me:15618: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings other than the usual output.
@@ -15711,11 +15710,11 @@
    -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:15714: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:15713: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>out/conftest.err)
    ac_status=$?
    cat out/conftest.err >&5
-   echo "$as_me:15718: \$? = $ac_status" >&5
+   echo "$as_me:15717: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s out/conftest2.$ac_objext
    then
      # The compiler can only warn and ignore the option if not recognized
@@ -15763,11 +15762,11 @@
    -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:15766: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:15765: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>out/conftest.err)
    ac_status=$?
    cat out/conftest.err >&5
-   echo "$as_me:15770: \$? = $ac_status" >&5
+   echo "$as_me:15769: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s out/conftest2.$ac_objext
    then
      # The compiler can only warn and ignore the option if not recognized
@@ -17179,11 +17178,11 @@
    -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:17182: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:17181: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:17186: \$? = $ac_status" >&5
+   echo "$as_me:17185: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings other than the usual output.
@@ -17512,11 +17511,11 @@
    -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:17515: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:17514: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:17519: \$? = $ac_status" >&5
+   echo "$as_me:17518: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings other than the usual output.
@@ -17611,11 +17610,11 @@
    -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:17614: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:17613: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>out/conftest.err)
    ac_status=$?
    cat out/conftest.err >&5
-   echo "$as_me:17618: \$? = $ac_status" >&5
+   echo "$as_me:17617: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s out/conftest2.$ac_objext
    then
      # The compiler can only warn and ignore the option if not recognized
@@ -17663,11 +17662,11 @@
    -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:17666: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:17665: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>out/conftest.err)
    ac_status=$?
    cat out/conftest.err >&5
-   echo "$as_me:17670: \$? = $ac_status" >&5
+   echo "$as_me:17669: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s out/conftest2.$ac_objext
    then
      # The compiler can only warn and ignore the option if not recognized
@@ -19265,7 +19264,7 @@
   enableval=$enable_sjlj_exceptions; :
 else
   cat > conftest.$ac_ext << EOF
-#line 19268 "configure"
+#line 19267 "configure"
 struct S { ~S(); };
 void bar();
 void foo()
@@ -19595,6 +19594,9 @@
         SYSTEMSPEC="-lunicows $SYSTEMSPEC"
       fi
     ;;
+    *-*-darwin[912]*)
+      SYSTEMSPEC="-allow_stack_execute"
+    ;;
     *)
       SYSTEMSPEC=
     ;;
@@ -20346,9 +20348,6 @@
     # on Darwin -single_module speeds up loading of the dynamic libraries.
     extra_ldflags_libjava=-Wl,-single_module
     ;;
-*-*-darwin[912]*)
-    extra_gij_ldflags=-Wl,-allow_stack_execute
-    ;;
 arm*linux*eabi)
     # Some of the ARM unwinder code is actually in libstdc++.  We
     # could in principle replicate it in libgcj, but it's better to
@@ -20367,7 +20366,6 @@
 
 
 
-
 # Allow the GC to be disabled.  Can be useful when debugging.
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for garbage collector to use" >&5
 $as_echo_n "checking for garbage collector to use... " >&6; }
Index: Makefile.am
===================================================================
--- Makefile.am	(revision 154954)
+++ Makefile.am	(working copy)
@@ -1065,8 +1065,7 @@
 ## need this because we are explicitly using libtool to link using the
 ## `.la' file.
 gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \
-	-shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \
-	$(extra_gij_ldflags) 
+	-shared-libgcc $(THREADLDFLAGS) $(extra_ldflags)
 gij_LINK = $(GCJLINK) $(gij_LDFLAGS)
 ## See jv_convert_LDADD.
 gij_LDADD = -L$(here)/.libs libgij.la

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Fri, Dec 04, 2009 at 03:48:03PM +0000, Andrew Haley wrote:
> Jack Howarth wrote:
> > On Fri, Dec 04, 2009 at 02:59:43PM +0000, Andrew Haley wrote:
> >>>      I suspect we may have a layered problem here and need
> >>> to work through each section. This weekend, I do some additional
> >>> builds to verify that the crash debugs to the same locations
> >>> in both darwin9 and darwin10 with and without the proposed
> >>> patch to pass -Wl,-allow_stack_execute on GCJLINK.
> >> Right.
> >>
> > 
> > Andrew,
> >    Just to double check, you do agree that everything linked with 
> > GCJLINK should be passed -Wl,-allow_stack_execute on darwin9/darwin10?
> 
> I think so.
> 
> > I am a bit confused by the criteria used to determine which java binaries
> > need the ld flag for -allow_stack_execute. If the a shared library contains
> > code that needs to execute on the stack
> 
> No gcj library needs to execute on the stack, only the heap.  I think the flag
> is misnamed.
> 
> > (libgcj) shouldn't any executable
> > that links in that shared lib use the -allow_stack_execute ld flag?
> 
> Yes, which is why I suggested you use SYSTEMSPEC.  (Twice now, I think.  :-)
> 
> SYSTEMSPEC should pass that flag to everything liked with gcj.
> 
> Andrew.

Andrew,
    I tried SYSTEMSPEC last night and it didn't eliminate the crashes in gcj. I'll double
check that tonight and specifically look for when libtool is using gcj to link to make
sure the -allow_stack_execute flag is invoked. If so, I'll make sure that the location of
the crash in gcj has shifted as it did when passing -Wl,-allow_stack_execute on GCJLINK.
                Jack
ps Should I take this to mean that SYSTEMSPEC will cause gcj to automatically pass
-Wl,-allow_stack_execute when it links code? I assume I should be able to see that with
-v being pased to gcj. What confuses me is that gcj -v shows ejc1 being invoked. So
does ecj1 get the -Wl,-allow_stack_execute passed on from gcj or should it be invoking
-Wl,-allow_stack_execute on its own from SYSTEMSPEC?

Re: [patch] Fix oddity in personality routine

[Andrew Haley]

Jack Howarth wrote:
> On Fri, Dec 04, 2009 at 03:48:03PM +0000, Andrew Haley wrote:
>> Jack Howarth wrote:
>>> On Fri, Dec 04, 2009 at 02:59:43PM +0000, Andrew Haley wrote:
>>>>>      I suspect we may have a layered problem here and need
>>>>> to work through each section. This weekend, I do some additional
>>>>> builds to verify that the crash debugs to the same locations
>>>>> in both darwin9 and darwin10 with and without the proposed
>>>>> patch to pass -Wl,-allow_stack_execute on GCJLINK.
>>>> Right.
>>>>
>>> Andrew,
>>>    Just to double check, you do agree that everything linked with 
>>> GCJLINK should be passed -Wl,-allow_stack_execute on darwin9/darwin10?
>> I think so.
>>
>>> I am a bit confused by the criteria used to determine which java binaries
>>> need the ld flag for -allow_stack_execute. If the a shared library contains
>>> code that needs to execute on the stack
>> No gcj library needs to execute on the stack, only the heap.  I think the flag
>> is misnamed.
>>
>>> (libgcj) shouldn't any executable
>>> that links in that shared lib use the -allow_stack_execute ld flag?
>> Yes, which is why I suggested you use SYSTEMSPEC.  (Twice now, I think.  :-)
>>
>> SYSTEMSPEC should pass that flag to everything liked with gcj.

>     I tried SYSTEMSPEC last night and it didn't eliminate the crashes in gcj. I'll double
> check that tonight and specifically look for when libtool is using gcj to link to make
> sure the -allow_stack_execute flag is invoked. If so, I'll make sure that the location of
> the crash in gcj has shifted as it did when passing -Wl,-allow_stack_execute on GCJLINK.

OK.

> ps Should I take this to mean that SYSTEMSPEC will cause gcj to automatically pass
> -Wl,-allow_stack_execute when it links code? I assume I should be able to see that with
> -v being pased to gcj.

Yes.  This should work everywhere, all the time.

> What confuses me is that gcj -v shows ejc1 being invoked.

Yes.

> So does ecj1 get the -Wl,-allow_stack_execute passed on from gcj or should it be invoking
> -Wl,-allow_stack_execute on its own from SYSTEMSPEC?

ecj1 doesn't get passed -allow_stack_execute, the linker does.  Adding -allow_stack_execute
to SYSTEMSPEC will make sure that the linker is always passed this command.

Bryce's patch is right, I think.

Andrew.

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Fri, Dec 04, 2009 at 03:57:11PM +0000, Bryce McKinlay wrote:
> On Fri, Dec 4, 2009 at 3:48 PM, Andrew Haley <aph@redhat.com> wrote:
> 
> > Yes, which is why I suggested you use SYSTEMSPEC.  (Twice now, I think.  :-)
> >
> > SYSTEMSPEC should pass that flag to everything liked with gcj.
> 
> Jack,
> 
> Here's a patch that adds the allow_stack_execute flag to SYSTEMSPEC as
> suggested by Andrew.
> 
> It does not fix the problem with ecj, but I agree it's a good idea.
> 
> Bryce

Bryce,
   Your proposed patch builds libjava normally on x86_64-apple-darwin10
and I now see...

#
# This spec file is read by gcj when linking.
# It is used to specify the standard libraries we need in order
# to link with libgcj.
#
%rename startfile startfileorig
*startfile:  %(startfileorig)

%rename lib liborig
*lib:  %{s-bc-abi:} -lgcj  -lm -L/sw/lib -liconv  -lpthread -lz -allow_stack_execute  -ldl %(libgcc)  %(liborig)

*jc1: -fhash-synchronization -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fnon-call-exceptions     -fkeep-inline-functions

in /sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.2.0/4.5.0/../../../libgcj.spec instead of...

#
# This spec file is read by gcj when linking.
# It is used to specify the standard libraries we need in order
# to link with libgcj.
#
%rename startfile startfileorig
*startfile:  %(startfileorig)

%rename lib liborig
*lib:  %{s-bc-abi:} -lgcj  -lm -L/sw/lib -liconv  -lpthread -lz   -ldl %(libgcc)  %(liborig)

*jc1: -fhash-synchronization -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fnon-call-exceptions     -fkeep-inline-functions

Linking with gcj -v also reveals that -allow_stack_execute is being passed to collect2
as expected. Can we get this in to gcc trunk as an obvious change?
                      Jack
ps Gcj still crashes compiling java as I saw yesterday with the alternative approach to passing -stack_allow_execute...

[MacPro:~] howarth% gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/ecj1
GNU gdb 6.3.50-20050815 (Apple version gdb-1346) (Fri Sep 18 20:40:51 UTC 2009)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ...... done

warning: Could not find object file "/var/tmp//cckmtKiq.o" - no debug information available for "/var/tmp//cc4vWuF2.i".


(gdb) break ../../../gcc-4.5-20091204/libjava/gnu/classpath/natVMStackWalker.cc:104
Breakpoint 1 at 0x20c49ba4ad2864: file ../../../gcc-4.5-20091204/libjava/gnu/classpath/natVMStackWalker.cc, line 104.
Breakpoint 2 at 0x20c49ba4ad28a0: file ../../../gcc-4.5-20091204/libjava/gnu/classpath/natVMStackWalker.cc, line 104.
warning: Multiple breakpoints were set.
Use the "delete" command to delete unwanted breakpoints.
(gdb) r testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/share/xtal/ccp4-6.1.2/bin/:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccf5cqZS.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccK4ZxH8.jar
Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/ecj1 testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/share/xtal/ccp4-6.1.2/bin/:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccf5cqZS.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccK4ZxH8.jar
Reading symbols for shared libraries +++++. done

Breakpoint 1, gnu::classpath::VMStackWalker::getCallingClassLoader (pc=0x10098d774) at ../../../gcc-4.5-20091204/libjava/gnu/classpath/natVMStackWalker.cc:104
104	  jclass klass = GET_CALLING_CLASS(pc);
(gdb) s
Current language:  auto; currently c++
0x0000000100994db2 in dyld_stub__Unwind_FindEnclosingFunction ()
(gdb) s
Single stepping until exit from function dyld_stub__Unwind_FindEnclosingFunction, 
which has no line number information.
0x00007fff844bffc0 in _Unwind_FindEnclosingFunction ()
(gdb) s
Single stepping until exit from function _Unwind_FindEnclosingFunction, 
which has no line number information.

Program received signal SIGABRT, Aborted.
0x00007fff843d4fe6 in __kill ()
(gdb) 

I'll repeat this build on x86_64-apple-darwin9 tomorrow to verify that in both darwin9 and
darwin10 (with the proper passing of -allow_stack_execute) that the crash has moved to the
same location and update the PR. Thanks again for the patch.
                Jack
ps After I verify that stock gcc trunk behaves the same under darwin9 with the above patch,
I'll rebuild gcc trunk with the libgcc_ext changes regressed out to verify that the FSF libgcc
and the system libgcc unwinder are both failing in the same manner on darwin9. This will also
allow me to walk the unwinder (as unfortunately Apple's libgcc and libSystem unwinders don't
ship with debug code...sigh). 

Re: [patch] Fix oddity in personality routine

[Jack Howarth]

On Fri, Dec 04, 2009 at 03:57:11PM +0000, Bryce McKinlay wrote:
> On Fri, Dec 4, 2009 at 3:48 PM, Andrew Haley <aph@redhat.com> wrote:
> 
> > Yes, which is why I suggested you use SYSTEMSPEC.  (Twice now, I think.  :-)
> >
> > SYSTEMSPEC should pass that flag to everything liked with gcj.
> 
> Jack,
> 
> Here's a patch that adds the allow_stack_execute flag to SYSTEMSPEC as
> suggested by Andrew.
> 
> It does not fix the problem with ecj, but I agree it's a good idea.
> 
> Bryce

Bryce,
    Your patch eliminates the crashes in gcj completely for gcc trunk
on x86_64-apple-darwin9 if I also regress out r154282 and r154283
so that the FSF libgcc's unwinder is used again. So we are starting
to peel the layers off of the problem. Your patch definitely should
go into gcc trunk and gcc 4.4 branch (where it will be immediately
useful on darwin9 since the libgcc_ext changes don't exist there).
     In case you are unaware, the r154282 and r154283 commits
introduced a new libgcc_ext shared library on darwin to provide
the additional symbols that have been added to libgcc since the
libgcc 10.4 and 10.5 stubs were defined. One 'feature' of this
change is that both the system libgcc and the FSF libgcc are linked
in. The logic is that since the 10.4/10.5 stubs are no longer built
on FSF gcc trunk, those symbols will be provided by the first 
libgcc to be linked in (which is the system's). The second libgcc_s
linked in comes from FSF gcc and provides the additional symbols
via the 10.4/10.5 libgcc_ext stubs. Mike Stump approved the logic
of all of this.
    I will revert back to the r154282 and r154283 commits being
in place under darwin9. When the system libgcc is used under
darwin9 (which is now the default behavior in gcc trunk for
darwin), gcj crashes with your patch in place when compiling
java code...

Breakpoint 1 (./../../gcc-4.5-20091204/libjava/exception.cc:128) pending.
(gdb) r testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccamdOl5.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccaNqaGi.jar
Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1 testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccamdOl5.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccaNqaGi.jar
warning: posix_spawn failed, trying execvp, error: 86
Reading symbols for shared libraries ++++.+. done

Program received signal SIGABRT, Aborted.
0x00007fff810c3f16 in __kill ()
(gdb) bt
#0  0x00007fff810c3f16 in __kill ()
#1  0x00007fff81134f6d in abort ()
#2  0x000000010001342b in _Jv_Throw (value=0x10483e6c0) at ../../../gcc-4.5-20091204/libjava/exception.cc:128
Previous frame inner to this frame (gdb could not unwind past this frame)

This crash appears to be different from that seen under darwin10. That might not be surprising as the
unwinder is a different one subsumed into libSystem in that case. Unfortunately it won't be trivial
to get debug code for the system unwinder. Hopefully, I can just use the approach of examining the
assembly at the address of the crash to define the scope of the problem in both darwin9 and darwin10.
In any case, we have made significant progress towards solving PR41991. Thanks in advance for
any help in getting your patch into gcc trunk and 4.4 branch as an obvious fix.
                 Jack