From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8439 invoked by alias); 18 Mar 2009 03:24:20 -0000 Received: (qmail 7902 invoked by uid 22791); 18 Mar 2009 03:24:17 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 18 Mar 2009 03:24:11 +0000 Received: from spaceape9.eur.corp.google.com (spaceape9.eur.corp.google.com [172.28.16.143]) by smtp-out.google.com with ESMTP id n2I3O75O001659 for ; Wed, 18 Mar 2009 03:24:07 GMT Received: from gxk10 (gxk10.prod.google.com [10.202.11.10]) by spaceape9.eur.corp.google.com with ESMTP id n2I3O5P7009088 for ; Tue, 17 Mar 2009 20:24:06 -0700 Received: by gxk10 with SMTP id 10so533023gxk.20 for ; Tue, 17 Mar 2009 20:24:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.177.13 with SMTP id z13mr36832wfe.196.1237346644762; Tue, 17 Mar 2009 20:24:04 -0700 (PDT) In-Reply-To: <20090318031516.GL31979@adacore.com> References: <20090205030257.8A6073A6B7A@localhost> <20090305200415.GC3744@adacore.com> <8ac60eac0903051546r1eaffc89tf1f35b21e6dc1b40@mail.gmail.com> <200903180249.10903.pedro@codesourcery.com> <20090318031516.GL31979@adacore.com> Date: Wed, 18 Mar 2009 04:06:00 -0000 Message-ID: <8ac60eac0903172024g4e381249t43bac2b4c9769a04@mail.gmail.com> Subject: Re: [patch] Fix a crash when displaying variables from shared ?library. From: Paul Pluzhnikov To: Joel Brobecker Cc: Pedro Alves , gdb-patches@sourceware.org, tromey@redhat.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-System-Of-Record: true X-IsSubscribed: yes 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 X-SW-Source: 2009-03/txt/msg00358.txt.bz2 On Tue, Mar 17, 2009 at 8:15 PM, Joel Brobecker wrote: > If I understand the original issue correctly, we need to restart > the execution of our program in order to demonstrate the issue. Well, not really. You could also dlopen foo.so break in foo.so display something referring to foo.so symbols dlclose foo.so re-display But writing a portable test for that is harder. > Except with the extended-remote protocol, we can't do that when > using the gdbserver, right? In other words, the "run" command with > target remote doesn't restart the program like in the native case. > So I'd say we kill the test for remote targets. Is it as simple as removing changing fail to untested: if { [gdb_start_cmd] < 0 } { - fail "Can't run to main (2)" + untested "Can't run to main (2)" return 0 } Of course we might just as well skip the test, since it's not going to test much in that case. -- Paul Pluzhnikov