public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: java/6092: sparc-sun-solaris2.7 has hundreds of libjava failures with -m64 Date: Sat, 30 Mar 2002 12:36:00 -0000 [thread overview] Message-ID: <20020330203601.26388.qmail@sources.redhat.com> (raw) The following reply was made to PR java/6092; it has been noted by GNATS. From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> To: tromey@redhat.com Cc: gcc-gnats@gcc.gnu.org Subject: Re: java/6092: sparc-sun-solaris2.7 has hundreds of libjava failures with -m64 Date: Sat, 30 Mar 2002 15:33:58 -0500 (EST) > From: Tom Tromey <tromey@redhat.com> > > >>>>> "Kaveh" == Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes: > > Kaveh> I looked at last night's testrun to see the context around each > Kaveh> failure. Unfortunately there aren't any useful error messages, it > Kaveh> just compiles/PASSes and then spawn FAILs the run. I've included a > Kaveh> bunch of them here using "grep -B 3 ^FAIL libjava.log" so you can see > Kaveh> what I mean. > > Maybe running dejagnu with `--verbose' will give more information. Ok, I ran it with RUNTESTFLAGS containing --verbose in addition to the --target_board and it did say a little more between the spawn and the FAIL line. Now I get mysterious crash messages like this: spawn [open ...] 7 file6 close result is child killed: illegal instruction got or this: spawn [open ...]^M 7 file6 close result is child killed: SIGABRT got or this: spawn [open ...]^M 7 file6 close result is child killed: segmentation violation (I don't know what the "7 file6" means.) However, I also get lots of random other failures about "output from source compiled test" or "output from bytecode->native test" doesn't match. So there doesn't seem to be an obvious pattern. > The libjava test suite doesn't remove an executable if it fails. So > you could also try running the executable by hand to see if it fails > outside the test suite. (This isn't always perfectly accurate due to > environmental differences; for instance the test suite sets > LD_LIBRARY_PATH.) > Thanks for looking at this. > Tom Hmm, actually it *does* remove the FAILed executables. Well, let's see, I was running several passes and the -m64 pass goes first. I guess the subsequent passes without -m64 PASSed these tests and removed the executable. :-) So I reran it by hand and caught one of the executable files at random (Array_3) before the next pass started. I had to setup LD_LIBRARY_PATH to contain the right directories (I think), here's what I get from `ldd Array_3' showing what shared libs will be used: libm.so.1 => /usr/lib/64/libm.so.1 libgcc_s_sparcv9.so.1 => /teal/caip5/ghazi/gcc-testing/branch/build/gcc/libgcc_s_sparcv9.so.1 libgcj.so.3 => /teal/caip5/ghazi/gcc-testing/branch/build/sparc-sun-solaris2.7/sparcv9/libjava/.libs/libgcj.so.3 libpthread.so.1 => /usr/lib/64/libpthread.so.1 librt.so.1 => /usr/lib/64/librt.so.1 libsocket.so.1 => /usr/lib/64/libsocket.so.1 libnsl.so.1 => /usr/lib/64/libnsl.so.1 libdl.so.1 => /usr/lib/64/libdl.so.1 libc.so.1 => /usr/lib/64/libc.so.1 libaio.so.1 => /usr/lib/64/libaio.so.1 libmp.so.2 => /usr/lib/64/libmp.so.2 libthread.so.1 => /usr/lib/64/libthread.so.1 /usr/platform/SUNW,Ultra-Enterprise-10000/lib/sparcv9/libc_psr.so.1 That seems ok. So I ran it and got: Abort (core dumped) I tried it under gdb-4.18, but it said: Array_3": not in executable format: File format not recognized I went to another machine that had gdb 5.0 installed and got: Starting program: /teal/caip5/ghazi/gcc-testing/branch/build/sparc-sun-solaris2.7/libjava/testsuite/Array_3 procfs:4036 -- process not stopped. procfs: ...giving up... After that I gave up. (I don't know whether the gdb problem is because gdb doesn't understand -m64 executables or because it doesn't understand java produced code or maybe the local installation was broken.) If you'd like me to attempt anything else let me know. Alternatively, you could get a solaris2 box and run make check with: setenv RUNTESTFLAGS "--verbose --target_board='unix{-m64,}'" to get both regular and -m64 passes. Thanks for your help. --Kaveh -- Kaveh R. Ghazi Director of Systems Architecture ghazi@caip.rutgers.edu Qwest Global Services
next reply other threads:[~2002-03-30 20:36 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-03-30 12:36 Kaveh R. Ghazi [this message] -- strict thread matches above, loose matches on Subject: below -- 2002-04-10 18:06 Tom Tromey 2002-03-30 22:06 Kaveh R. Ghazi 2002-03-30 21:46 Tom Tromey 2002-03-30 21:26 Kaveh R. Ghazi 2002-03-30 14:56 Tom Tromey 2002-03-29 11:16 Tom Tromey 2002-03-29 11:06 Kaveh R. Ghazi 2002-03-29 8:56 Tom Tromey 2002-03-29 8:16 ghazi
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20020330203601.26388.qmail@sources.redhat.com \ --to=ghazi@caip.rutgers.edu \ --cc=gcc-prs@gcc.gnu.org \ --cc=nobody@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).