From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14641 invoked by alias); 24 Apr 2013 14:09:32 -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 14628 invoked by uid 89); 24 Apr 2013 14:09:32 -0000 X-Spam-SWARE-Status: No, score=-8.4 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 24 Apr 2013 14:09:31 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r3OE9SWm000996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Apr 2013 10:09:28 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r3OE9Qtv021676; Wed, 24 Apr 2013 10:09:27 -0400 Message-ID: <5177E796.1060605@redhat.com> Date: Wed, 24 Apr 2013 17:46:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Nicolas Blanc CC: gdb-patches@sourceware.org Subject: Re: [PATCH 0/3] remove-symbol-file References: <1366098721-18302-1-git-send-email-nicolas.blanc@intel.com> In-Reply-To: <1366098721-18302-1-git-send-email-nicolas.blanc@intel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-04/txt/msg00737.txt.bz2 On 04/16/2013 08:51 AM, Nicolas Blanc wrote: > This patch adds a command for removing individual symbol files. > > The symbol-file command without parameter can be used to clear > all symbol-file information. This command is not practical if > the user needs to remove just one file, however. > > Apple provides its own remove-symbol-file command but the code > was not upstreamed [1]. I provide here my own implementation. > There are two main differences between the command from Apple and > mine: > > 1) The remove-symbol-file command from Apple takes as parameter > the file to remove whereas this implementation requires the load > address of the file. Hence, this command is able to unload > symbol for files that have been loaded multiple times. Some points to consider on the interface/spec/requirements, before the user interface is carved in stone. Doesn't it also make it more complicated to use for the more common case of not loading files multiple times? For the case of multiple symbol files with the same file, we could warn/query the user to remove all with the same file. I believe one can actually load overlapping files with add-symbol-file. So "load address" is not a unique identifier, though in practice it'll work most of the time. Also, "load address" is not clear here. With "add-symbol-file", the specified addresses is actually the ".text" section's address. (gdb) help add-symbol-file Load symbols from FILE, assuming FILE has been dynamically loaded. Usage: add-symbol-file FILE ADDR [-s -s ...] ADDR is the starting address of the file's text. ... if (argcnt == 1) { /* The second argument is always the text address at which to load the program. */ sect_opts[section_index].name = ".text"; sect_opts[section_index].value = arg; ... This actually looks a bit problematic for the remove case, because there may not be a .text segment at all, or the .text section may not be the lowest section loaded in the text segment, or the text segment may not be the lowest loaded segment. In the add case, if there's no .text, you pass in a random ADDR, I believe. So should we consider mirroring the add-symbol-file syntax? remove-symbol-file FILE remove-symbol-file FILE ADDR remove-symbol-file -s .data DATA_ADDR And in all cases, if there are overlapping symbol files, warn/remove all that match? How are manually added symbol files listed, BTW? Should we have a new "info symbol-files" command listing manually added symbol files? Maybe we should have a unique number to each symbol file? Then the user could list and remove them by number (like e.g., breakpoints) instead. Or maybe even generalize that into "info objfiles". Dunno. > I would appreciate feedback from the maintainers of GDB at Apple to > help upstream a command that satisfies the community at large. There are none. Apple stopped caring about upstream GDB long ago. -- Pedro Alves