From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29490 invoked by alias); 25 Apr 2013 08:38:57 -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 29479 invoked by uid 89); 25 Apr 2013 08:38:56 -0000 X-Spam-SWARE-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.1 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 25 Apr 2013 08:38:56 +0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 25 Apr 2013 01:38:53 -0700 X-ExtLoop1: 1 Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by azsmga001.ch.intel.com with ESMTP; 25 Apr 2013 01:38:51 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.244]) by IRSMSX103.ger.corp.intel.com ([169.254.3.198]) with mapi id 14.01.0355.002; Thu, 25 Apr 2013 09:38:50 +0100 From: "Blanc, Nicolas" To: Pedro Alves CC: Tom Tromey , "gdb-patches@sourceware.org" Subject: RE: [PATCH 0/3] remove-symbol-file Date: Thu, 25 Apr 2013 17:25:00 -0000 Message-ID: <388084C8C1E6A64FA36AD1D656E4856619DEF279@IRSMSX102.ger.corp.intel.com> References: <1366098721-18302-1-git-send-email-nicolas.blanc@intel.com> <8761zdow5j.fsf@fleche.redhat.com> <388084C8C1E6A64FA36AD1D656E4856619DEEE98@IRSMSX102.ger.corp.intel.com> <51781A68.4010004@redhat.com> In-Reply-To: <51781A68.4010004@redhat.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2013-04/txt/msg00778.txt.bz2 >> session. In this context I think the text address is the most appropriat= e way to remove a file because: >> 1) the user knows exactly where the .text section was loaded, > > So how do you handle the case of there being no .text section at all? It's a requirement of the add-symbol-file command [1]. The existing impleme= ntation of add-symbol-file assumes that the *mandatory* load-address argument (terminology from GDB's manual) = is the address of the text section. See the implementation of add-symbol-file: if (argcnt =3D=3D 1) { /* The second argument is always the text address at which to load the program. */ sect_opts[section_index].name =3D ".text"; The second argument is not optional. The add-symbol-file command returns an= error if no address is specified. >> Note that currently in Option 4 below ADDR is in fact=20 >> "objf->addr_low", but the command could be more generous by searching=20 >> first which file corresponds to ADDR and then removing it. This would be= more flexible and an alternative to Option 3, for instance. >You lost me here. It's an idea that you and Tom gave me. Given an arbitrary address, remove-s= ymbol-file could figure out the file that corresponds to this address and remove it. This could make the command more= flexible. But thinking twice I think that the current implementation of remove-symbol-file does the right thing by identifying th= e file to remove using the address from the add-symbol-file command. The user knows what address he passed to add-symbo= l-file. >>=20 >> 1) remove-symbol-file FILE >> 2) remove-symbol-file FILE ADDR >> 3) remove-symbol-file -s .data DATA_ADDR >> 4) remove-symbol-file ADDR [1]=20 add-symbol-file filename address add-symbol-file filename address [ -readnow ] add-symbol-file filename address -s section address ... The add-symbol-file command reads additional symbol table information from = the file filename. You would use this command when filename has been dynami= cally loaded (by some other means) into the program that is running. addres= s should be the memory address at which the file has been loaded; gdb canno= t figure this out for itself. Nicolas Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052