From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68743 invoked by alias); 15 Jul 2015 16:58:57 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 68730 invoked by uid 89); 15 Jul 2015 16:58:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 15 Jul 2015 16:58:55 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 2B20A371B60; Wed, 15 Jul 2015 16:58:54 +0000 (UTC) Received: from host1.jankratochvil.net (ovpn-116-41.ams2.redhat.com [10.36.116.41]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6FGwoc7027218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Jul 2015 12:58:52 -0400 Date: Wed, 15 Jul 2015 16:58:00 -0000 From: Jan Kratochvil To: Yao Qi Cc: Pedro Alves , gdb-patches@sourceware.org, Andreas Arnez Subject: Re: ping: [testsuite patch] for: [PATCH] [PR corefiles/17808] i386: Fix internal error when prstatus in core file is too big Message-ID: <20150715165849.GA12070@host1.jankratochvil.net> References: <874ms18cyz.fsf@br87z6lw.de.ibm.com> <20150108164327.GA29029@host2.jankratochvil.net> <20150205073758.GA25305@host1.jankratochvil.net> <54D33C45.4010706@redhat.com> <20150214151231.GA29106@host1.jankratochvil.net> <54E33A8D.80504@redhat.com> <20150217165629.GA24936@host1.jankratochvil.net> <55A4CDD1.6060907@gmail.com> <20150714180748.GA13461@host1.jankratochvil.net> <86fv4pjt4m.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86fv4pjt4m.fsf@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00456.txt.bz2 On Wed, 15 Jul 2015 18:14:01 +0200, Yao Qi wrote: > Jan Kratochvil writes: > > > (1) The testcase did not really test if elf64-i386 is supported by GDB (BFD). > > That was OK for a Fedora testcase but I forgot about it when submitting it > > upstream. > > > > I haven't really verified if the GNU target is elf64-little but it seems so, > > no other one seems suitable from: > > elf32-x86-64 > > elf64-big > > elf64-k1om > > elf64-l1om > > elf64-little > > elf64-x86-64 > > pei-x86-64 > > Hi Jan, > Why can't we use istarget here? I do not know much dejagnu but I expect 'istarget' tests against the site.exp 'target_triplet' content which is set to the primary GDB target (--target=...). GDB is normally never configured for primary target elf64-i386, I think BFD does not know such explicit target, it gets recognized as elf64-little. In fact many testfiles of the GDB testsuite are wrong as they require 'istarget' (therefore primary GDB target) even for just loading arch specific files which would be sufficient with secondary target (--enable-targets=...) support. > I thought we still check istarget "x86_64-*-*", no? This my new patch removes this 'istarget' check as it is IMO unrelated to what we need to test. Although you are right we do 'x/i' and test for 'hlt' so I think we should test also for available 'set architecture i386'. We could also test by 'x/bx' instead of 'x/i' to avoid such additional test/requirement. > > (2) The output of the "core-file" command itself can be arbitrary as the > > elf64-i386 file with x86_64 registers is really broken; but that does not > > matter much, important is the following test whether core file memory is > > readable. > > "that does not matter much" mean if internal error isn't triggered, any > output is acceptable, right? Yes. > and the purpose of following test "x/i $address" > is to verify this (internal error not triggered)? I did not think specifically about internal error but I agree. After all the core file should be loaded which is tested by readability of a core file's segment. > > # Wrongly built GDB complains by: > > # "..." is not a core dump: File format not recognized > > # As the provided test core has 64bit PRSTATUS i386 built GDB cannot parse it. > > # This is just a problem of the test case, real-world elf64-i386 file will have > > # 32bit PRSTATUS. One cannot prepare elf64-i386 core file from elf32-i386 by > > # objcopy as it corrupts the core file beyond all recognition. > > As you said, the output of command "core-file" doesn't matter much, we > need to update the comments here. I think the comments above are useful to understand why it does not behave as sanely as one would expect (=the real world case for loading kdump i386 kernel core files). So to add another part of the comment? # The output therefore does not matter much, just we should not get # GDB internal error. Although this whole feature is becoming marginal as i386 kernels in enterprise usage (=kdump) have AFAIK mostly disappeared. > > -gdb_test "core-file ${corefile}" "\r\nwarning: Unexpected size of section `\\.reg/6901' in core file\\.\r\n.*Core was generated by `\[^\r\n\]*'\\.\r\nProgram terminated with signal SIGSEGV, Segmentation fault\\.\r\n.*" "core-file" > > +gdb_test "core-file ${corefile}" ".*" "core-file" > > > > > gdb_test "x/i $address" "\r\n\[ \t\]*$address:\[ \t\]*hlt\[ \t\]*" ".text is readable" > > We also need comment here to explain the purpose this "x/i $address" test. Such a comment? # Test readability of a core file segment memory. Jan