From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30471 invoked by alias); 17 Jan 2008 11:41:11 -0000 Received: (qmail 30463 invoked by uid 22791); 17 Jan 2008 11:41:10 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate8.de.ibm.com (HELO mtagate8.de.ibm.com) (195.212.29.157) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 17 Jan 2008 11:40:47 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate8.de.ibm.com (8.13.8/8.13.8) with ESMTP id m0HBeiZ5073100 for ; Thu, 17 Jan 2008 11:40:44 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m0HBein9733258 for ; Thu, 17 Jan 2008 12:40:44 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m0HBeh18027543 for ; Thu, 17 Jan 2008 12:40:44 +0100 Received: from bbkeks.de.ibm.com (dyn-9-152-248-46.boeblingen.de.ibm.com [9.152.248.46]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m0HBegep027498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2008 12:40:43 +0100 Message-ID: <478F3E4B.6050005@de.ibm.com> Date: Thu, 17 Jan 2008 11:41:00 -0000 From: Markus Deuling User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Joel Brobecker CC: Markus Deuling , gdb-patches@sourceware.org Subject: Re: [RFA] new set/show multiple-choice-auto-select commands (take 2) References: <20080116135551.GE20837@adacore.com> <478EF71D.4060007@de.ibm.com> <20080117102621.GB28020@adacore.com> In-Reply-To: <20080117102621.GB28020@adacore.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: 2008-01/txt/msg00436.txt.bz2 Hi Joel, Joel Brobecker schrieb: > > Let me clarify the current semantics of multiple-choice-auto-select. > The idea is that, if multiple-choice-auto-select is turned on, then > some "auto-select" will happen. Otherwise, no auto-select, and thus > a menu needs to be displayed in order for the expression to be > disambiguated. Now, in terms of the command itself: > > 1. set multiple-choice-auto-select off (default): > Auto-select is turned off, so the multiple-choice menu is > displayed, and the user must chose the ones he wants. > > 2. set multiple-choice-auto-select all: > In that case, the auto-select will automatically choose the "all" > choice. If the "all" option is not available because you are expected > to choose 1 and only 1 choice, then an error is triggered. > > 3. set multiple-choice-auto-select cancel: > In that case, the auto-select will automatically choose the "cancel" > option of the multiple-choice menu. > I fully agree. For my patch it means: 1. set multiple-choice-auto-select off (default): If there is 0 || 1 symbol found, GDB follows the "normal" code path. If > 1 symbol is found the user choice is invoked 2. set multiple-choice-auto-select all: If there is > 1 symbol found all symbols found are automagically taken for e.g. breakpoints. 3. set multiple-choice-auto-select cancel: I think I'll ignore this. It makes no sense in that case. What do you think about it? Does it make sense? The problem I saw and still see is the change of the default behaviour of GDB (and with that maybe the introduction of a lot of FAILs in the teststuite). The user has no possibility to avoid the user choice if there are > 1 symbols. For my understanding that would for example break MI in some cases, doesn't it? Maybe it has even more side-effects I don't see yet. That was the reason for me to have that feature switched off by default. > I spent some time familiarizing myself with -Bsymbolic and the way > you introduced handling of these duplicated symbol names. Although > you and Daniel thought that it would be a good idea to treat these > types of symbols differently from other ambiguous expressions, > I don't quite understand why. But regardless of that fact, it seems > that the semantics of what you'd like to do is different from what > I am introducing, and that you should therefore have your own option. I implemented this behavior originally for the Cell BE combined debugger. Cell BE has binaries consisting of PowerPC- and SPU-code. If there is a symbol foo in both the PowerPC- and the SPU-part then GDB would always resolve the foo symbol from PowerPC (main executable) file no matter if it stands in a "SPU thread" or not. GDB recognizes SPU binaries as shared libraries. ELF standard (v1.2) says about DT_SYMBOLIC (inserted by -Bsymbolic): "This element’s presence in a shared object library alters the dynamic linker’s symbol resolution algorithm for references within the library. Instead of starting a symbol search with the executable file, the dynamic linker starts from the shared object itself. If the shared object fails to supply the referenced symbol, the dynamic linker then searches the executable file and other shared objects as usual." So there are at least two types of shared libs showing the same lookup behaviour. This was the reason to implement the combined debugger functionality using a new common framework (solib callbacks) and at the same time also implement it for ELF libs. Regards, Markus -- Markus Deuling GNU Toolchain for Linux on Cell BE deuling@de.ibm.com