From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78117 invoked by alias); 16 Jul 2015 14:15:16 -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 78105 invoked by uid 89); 16 Jul 2015 14:15:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f169.google.com Received: from mail-pd0-f169.google.com (HELO mail-pd0-f169.google.com) (209.85.192.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 16 Jul 2015 14:15:14 +0000 Received: by pdbep18 with SMTP id ep18so46579733pdb.1 for ; Thu, 16 Jul 2015 07:15:13 -0700 (PDT) X-Received: by 10.70.140.101 with SMTP id rf5mr19269121pdb.112.1437056112870; Thu, 16 Jul 2015 07:15:12 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id fv5sm8177744pdb.19.2015.07.16.07.15.09 (version=TLS1_2 cipher=AES128-SHA256 bits=128/128); Thu, 16 Jul 2015 07:15:12 -0700 (PDT) From: Yao Qi To: Jan Kratochvil Cc: Yao Qi , 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 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> <20150715165849.GA12070@host1.jankratochvil.net> Date: Thu, 16 Jul 2015 14:15:00 -0000 In-Reply-To: <20150715165849.GA12070@host1.jankratochvil.net> (Jan Kratochvil's message of "Wed, 15 Jul 2015 18:58:49 +0200") Message-ID: <867fq0jijf.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00471.txt.bz2 Jan Kratochvil writes: > I think the comments above are useful to understand why it does not behav= e as > sanely as one would expect (=3Dthe 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. It looks good to me. > > Although this whole feature is becoming marginal as i386 kernels in enter= prise > usage (=3Dkdump) 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" >>=20 >> >=20=20 >> > gdb_test "x/i $address" "\r\n\[ \t\]*$address:\[ \t\]*hlt\[ >> > \t\]*" ".text is readable" >>=20 >> We also need comment here to explain the purpose this "x/i $address" tes= t. > > Such a comment? > # Test readability of a core file segment memory. Sorry, I should be more clear. Let me ask in another way, why do we need "x/i $address" test? Without the patch fixing PR 17808, GDB should crash on loading core-file, and we tested that. Why do we do this test and test whether ".text" is readable or not? --=20 Yao (=E9=BD=90=E5=B0=A7)