Re: [boehm-gc] Use thr_stksegment to determine Solaris stack base
On Wed, Mar 6, 2013 at 11:31 AM, Rainer Orth
wrote:
> This patch fixes the failures by backporting the use of thr_stksegment
> from gc 7.2c.
>
> Bootstrapped without regressions on i386-pc-solaris2.{9,10,11} and
> sparc-sun-solaris2.{9,10,11}, fixes the i386-pc-solaris2.11 failures.
>
> Ok for mainline?
Yes, thanks. Though of course, we really ought to update the entire GC tree!
Bryce
Re: [PATCH] Fix linking with -findirect-dispatch
On Tue, Apr 16, 2013 at 9:38 AM, Jakub Jelinek wrote: > On Tue, Apr 16, 2013 at 10:35:29AM +0200, Andreas Schwab wrote: >> Linking with -findirect-dispatch fails with this error: >> >> x86_64-linux-gcj -o ecjx -findirect-dispatch >> --main=org.eclipse.jdt.internal.compiler.batch.GCCMain >> ../../../gcc/libjava/../ecj.jar ecjx.o >> /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: >> /tmp/ccppO92n.o: undefined reference to symbol '_Jv_MonitorExit' >> /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: >> note: '_Jv_MonitorExit' is defined in DSO /usr/lib64/libgcj.so.13 so try >> adding it to the linker command line >> >> Andreas. >> >> * configure.ac (LIBGCJ_SPEC_LGCJ_BC): Append -lgcj. >> (libgcj_spec_lgcj_bc_override): Likewise. >> * configure: Regenerate. > > That doesn't look right, if -findirect-dispatch now newly needs > _Jv_MonitorExit (when has that been added?), then the symbol should > be added to libgcj_bc.so. That's right. -findirect-dispatch code should not link libgcj directly. _Jv_MonitorExit has always been defined in libgcj_bc (see libgcj_bc.c), so something else is going wrong here. Bryce
Re: [PATCH] Fix linking with -findirect-dispatch
On Tue, Apr 16, 2013 at 5:13 PM, Andreas Schwab wrote: > Jakub Jelinek writes: > >> I'm pretty sure when the changes were added for gcc 4.2 it worked just fine, > > I'm pretty sure it never worked as intented. It certainly _did_ work as intended previously. Though I've not tested it for a while. Bryce
Re: [libjava] XFAIL sourcelocation (PR libgcj/55637)
On Thu, Feb 20, 2014 at 12:05 PM, Rainer Orth wrote: > The libjava sourcelocation output test has been FAILing on mainline for > more than a year, with no sign of anything happening to resolve that. > To reduce testsuite noise, I suggest to XFAIL the test. In all mainline > test results from february, only a single set of testresults that > included libjava results (for ia64-suse-linux-gnu) didn't show those > failures. > > Tested with the appropriate runtest invocations on i386-pc-solaris2.11 > and x86_64-unknown-linux-gnu. > > Ok for mainline? OK. The fix for this is to have libjava use libbackttrace to get source line numbers, rather than rely on external addr2line. Bryce
Re: [PATCH] Set correct source location for deallocator calls
On Thu, Aug 30, 2012 at 3:28 PM, Richard Henderson wrote: > On 08/17/2012 03:02 PM, Dehao Chen wrote: >> I spend a whole day working on this, but find it very difficult to add >> such a java test because: >> >> * First, libjava testsuits are all runtime tests, i.e., it compiles >> the byte code to native code, execute it, and compares the output to >> expected output. There is no way to scan the assembly. >> * Though there is a way to derive the line number at runtime in java >> (using Exception().getStackTrace()), this method only works on VM, and >> the gcj generated native code does not get the lineno. >> >> Any suggestions on this? > > Hmm, not from me, unfortunately. Cc'ing the java list for clues. > I won't hang up the main patch for this though. libjava calls out to addr2line to get the line number and source file name for stack traces. As long as it can find addr2line you should get a line number - but some platforms don't have it. Ref: libjava/stacktrace.cc and libjava/gnu/gcj/runtime/NameFinder.java
Re: [PATCH] Set correct source location for deallocator calls
On Tue, Sep 4, 2012 at 5:07 PM, Dehao Chen wrote: > On Thu, Aug 30, 2012 at 9:33 AM, Richard Henderson wrote: >> On 08/30/2012 08:20 AM, Andrew Haley wrote: >>> Is the problem simply that the logic to >>> scan the assembly code isn't present in the libgcj testsuite? >> >> Yes, exactly. > > For this case, I don't think that we want a testcase to rely on > addr2line in the system. So how about that that we add a test when > assembly scan is available in libgcj testsuit? Once Ian Lance Taylor's libbacktrace patch is integrated (see: http://gcc.gnu.org/ml/gcc/2012-08/msg00317.html), we'll be able to get rid of the code that calls addr2line from libgcj. So, I think it would be fine to write a Java test case using Throwable.getStackTrace(). Whichever approach is easiest for you is fine. Bryce
Re: [PATCH] Set correct source location for deallocator calls
On Tue, Sep 4, 2012 at 5:39 PM, Andrew Haley wrote: > On 09/04/2012 05:32 PM, Bryce McKinlay wrote: >> On Tue, Sep 4, 2012 at 5:07 PM, Dehao Chen wrote: >>> On Thu, Aug 30, 2012 at 9:33 AM, Richard Henderson wrote: >>>> On 08/30/2012 08:20 AM, Andrew Haley wrote: >>>>> Is the problem simply that the logic to >>>>> scan the assembly code isn't present in the libgcj testsuite? >>>> >>>> Yes, exactly. >>> >>> For this case, I don't think that we want a testcase to rely on >>> addr2line in the system. So how about that that we add a test when >>> assembly scan is available in libgcj testsuit? >> >> Once Ian Lance Taylor's libbacktrace patch is integrated (see: >> http://gcc.gnu.org/ml/gcc/2012-08/msg00317.html), we'll be able to get >> rid of the code that calls addr2line from libgcj. > > As I understand it, Ian Taylor's backtrace patch is intended for use in > gcc development, and as he puts it "Since its use in GCC would > be purely for GCC developers, it's not essential that it be fully > portable." Not for gcj runtime. He's also planning to use it for libgo, and other gcc runtime libs have indicated interest. It doesn't have to work on all platforms, and I can't see how it would be any less portable than addr2line! Bryce
Re: [PATCH] Set correct source location for deallocator calls
On Tue, Sep 4, 2012 at 6:12 PM, Andrew Haley wrote: >> He's also planning to use it for libgo, and other gcc runtime libs >> have indicated interest. It doesn't have to work on all platforms, and >> I can't see how it would be any less portable than addr2line! > > I certainly can. Maybe once it's shaken-down so it's at least as > robust as what we have now it'll be OK. I suspect it hasn't had much > testing with, for example, unwinding through signal handlers. libgcj wouldn't actually use it for unwinding, we already have all that. We'd just use it to read DWARF debug info and give us the source code line numbers.
Re: [PATCH] [JAVA] Double.parseDouble(null) throw NullPointerException
On Fri, Aug 12, 2011 at 8:27 AM, Jie Liu wrote:
> The method length() is not a final method, as java/lang/String.java line 447:
>
> public int length()
> {
> return count;
> }
>
> Is this the problem?
As String is a final class, all its methods are implicitly final.
Bryce
