From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74102 invoked by alias); 27 Sep 2017 22:11:07 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 74092 invoked by uid 89); 27 Sep 2017 22:11:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=numerous, cisco, 7500, dennis X-HELO: jax4mhob05.myregisteredsite.com Received: from jax4mhob05.myregisteredsite.com (HELO jax4mhob05.myregisteredsite.com) (64.69.218.85) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 27 Sep 2017 22:11:05 +0000 Received: from mailpod.hostingplatform.com ([10.30.77.35]) by jax4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id v8RMB1sY002251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 27 Sep 2017 18:11:02 -0400 Received: (qmail 8637 invoked by uid 0); 27 Sep 2017 22:11:01 -0000 X-TCPREMOTEIP: 99.253.103.29 X-Authenticated-UID: dclarke@blastwave.org Received: from unknown (HELO ?172.16.35.9?) (dclarke@blastwave.org@99.253.103.29) by 0 with ESMTPA; 27 Sep 2017 22:11:01 -0000 Subject: Re: numerous tests fail in "make check" stage of gdb-8.0.1 on Debian 8.8 powerpc64 To: gdb@sourceware.org References: <4f35a691-10f3-bfef-17b1-705b7d624483@blastwave.org> From: Dennis Clarke Message-ID: Date: Wed, 27 Sep 2017 22:11:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00132.txt.bz2 On 09/27/2017 05:45 PM, Yao Qi wrote: > On Wed, Sep 27, 2017 at 2:34 PM, Dennis Clarke wrote: >> >> It is difficult to know if the entire gdb build should be tossed away or is >> this normal behavior ? >> > > GDB tests are never FAIL free, so some test fails don't mean GDB is > completely broken. However, > fails in these tests do means something is wrong. > I am not sure what to make of that. It means "something is wrong" and also "something is always wrong with gdb". The test results look like so : === gdb Summary === # of expected passes 33093 # of unexpected failures 96 # of expected failures 58 # of known failures 65 # of unresolved testcases 3 # of untested testcases 56 # of unsupported tests 206 /usr/local/build/gdb-8.0.1_linux_3.16.0-4-powerpc64.001/gdb/testsuite/../../gdb/gdb version 8.0.1 -nw -nx -data-directory /usr/local/build/gdb-8.0.1_linux_3.16.0-4-powerpc64.001/gdb/testsuite/../data-directory gmake[4]: *** [check-single] Error 1 gmake[4]: Leaving directory `/usr/local/build/gdb-8.0.1_linux_3.16.0-4-powerpc64.001/gdb/testsuite' gmake[3]: *** [check] Error 2 gmake[3]: Leaving directory `/usr/local/build/gdb-8.0.1_linux_3.16.0-4-powerpc64.001/gdb/testsuite' gmake[2]: *** [check] Error 2 gmake[2]: Leaving directory `/usr/local/build/gdb-8.0.1_linux_3.16.0-4-powerpc64.001/gdb' gmake[1]: *** [check-gdb] Error 2 gmake[1]: Leaving directory `/usr/local/build/gdb-8.0.1_linux_3.16.0-4-powerpc64.001' gmake: *** [do-check] Error 2 So there are 96 failures that were not expected. Also, the resultant gdb binary seems to have found my libiconv and libexpat but not libz : deb8_ppc64$ ldd ./gdb/gdb linux-vdso64.so.1 (0x00003fff7efe0000) libdl.so.2 => /lib64/libdl.so.2 (0x00003fff7efb0000) libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x00003fff7ef50000) libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x00003fff7ee30000) libm.so.6 => /lib64/libm.so.6 (0x00003fff7ed60000) libc.so.6 => /lib64/libc.so.6 (0x00003fff7eb90000) /lib64/ld64.so.1 (0x0000000051b20000) deb8_ppc64$ ls -lo /usr/local/lib/libz* -rw-r--r-- 1 root 333690 May 27 03:05 /usr/local/lib/libz.a lrwxrwxrwx 1 root 14 May 27 03:05 /usr/local/lib/libz.so -> libz.so.1.2.11 lrwxrwxrwx 1 root 14 May 27 03:05 /usr/local/lib/libz.so.1 -> libz.so.1.2.11 -rwxr-xr-x 1 root 236688 May 27 03:05 /usr/local/lib/libz.so.1.2.11 deb8_ppc64$ Not sure if I can install this or not. My whole reason for this is simply that gdb on the system won't work with a 64-bit binary and I don't know why : deb8_ppc64$ cat hello.c #include #include int main( int argc, char *argv[]) { fprintf ( stdout, "hello world.\n" ); return ( EXIT_SUCCESS ); } Compile it, run it and look at it : Code: deb8_ppc64$ gcc -m64 -g -o hello hello.c deb8_ppc64$ ./hello hello world. deb8_ppc64$ file hello hello: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.1, for GNU/Linux 2.6.32, BuildID[sha1]=c79bcf90665edeb4b1d9a5972c4f7ddf8ec9877d, not stripped deb8_ppc64$ deb8_ppc64$ which gdb /usr/bin/gdb deb8_ppc64$ ls -lap /usr/bin/gdb -rwxr-xr-x 1 root root 6301688 Nov 9 2014 /usr/bin/gdb deb8_ppc64$ /usr/bin/gdb hello GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... "/usr/local/src/test/hello/hello": not in executable format: File format not recognized (gdb) quit deb8_ppc64$ So I decided to simply get the source and build a new gdb. Which may not work very well given the tests above. Very difficult to tell what to do here. Dennis