From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19774 invoked by alias); 14 Jan 2014 21:32:28 -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 19762 invoked by uid 89); 14 Jan 2014 21:32:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_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 ESMTP; Tue, 14 Jan 2014 21:32:26 +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 (8.14.4/8.14.4) with ESMTP id s0ELWOxO025961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jan 2014 16:32:24 -0500 Received: from localhost.localdomain (ovpn-112-29.ams2.redhat.com [10.36.112.29]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s0ELWILk007187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Jan 2014 16:32:22 -0500 Date: Tue, 14 Jan 2014 21:32:00 -0000 From: Phil Muldoon To: Tom Tromey Cc: Hui Zhu , gdb-patches ml , Phil Muldoon Subject: Re: [PATCH] Make "backtrace" doesn't print python stack if init python dir get fail Message-ID: <20140114213218.GA24832@localhost.localdomain> Reply-To: pmuldoon@redhat.com References: <52974146.70805@mentor.com> <8761r7w85h.fsf@fleche.redhat.com> <529D8865.80503@mentor.com> <87li01smua.fsf@fleche.redhat.com> <529EDCA7.1090903@mentor.com> <87eh5j2vw0.fsf@fleche.redhat.com> <52AAF43B.5060603@mentor.com> <87vbxmwnn3.fsf@fleche.redhat.com> <87ha96wje5.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ha96wje5.fsf@fleche.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00481.txt.bz2 On Tue, 14 Jan 2014, Tom Tromey wrote: > >>>>> "Hui" == Tom Tromey writes: > > I've appended my current patch. It arranges to clear > gdb_python_initialized if the second stage of initialization fails. > And, it adds a check on gdb_python_initialized in a couple of spots that > we missed before. > > However, it still isn't quite right, due to this code in > finish_python_initialization: > > if (gdb_python_module == NULL) > { > gdbpy_print_stack (); > /* This is passed in one call to warning so that blank lines aren't > inserted between each line of text. */ > warning (_("\n" > "Could not load the Python gdb module from `%s'.\n" > "Limited Python support is available from the _gdb module.\n" > "Suggest passing --data-directory=/path/to/gdb/data-directory.\n"), > gdb_pythondir); > do_cleanups (cleanup); > return; > } > > The question is -- what should we really do here? > > One option is to set gdb_python_initialized = 0. > I think this makes the warning text obsolete, though, since the > "limited" support would not actually be available at all (e.g., the > "python" command wouldn't work at all). I think the suggestion in the warning text is still good though? > I lean toward the simpler solution of changing the warning message and > clearing the flag. I think so too, it makes things simpler for the user. But in this patch you deleted the warning, so not sure if the patch you posted is your preferred solution? Cheers, Phil