From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6189 invoked by alias); 28 May 2013 11:25: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 6179 invoked by uid 89); 28 May 2013 11:25:28 -0000 X-Spam-SWARE-Status: No, score=-6.1 required=5.0 tests=AWL,BAYES_20,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_PASS,TW_BJ autolearn=ham version=3.3.1 Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 28 May 2013 11:25:26 +0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 28 May 2013 04:25:16 -0700 X-ExtLoop1: 1 Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga001.jf.intel.com with ESMTP; 28 May 2013 04:25:15 -0700 Received: from irsmsx106.ger.corp.intel.com ([169.254.8.225]) by IRSMSX101.ger.corp.intel.com ([169.254.1.127]) with mapi id 14.03.0123.003; Tue, 28 May 2013 12:25:14 +0100 From: "Blanc, Nicolas" To: Pedro Alves CC: "gdb-patches@sourceware.org" Subject: RE: [PATCH 1/3] Added command remove-symbol-file. Date: Tue, 28 May 2013 11:25:00 -0000 Message-ID: <388084C8C1E6A64FA36AD1D656E485661A79962D@IRSMSX106.ger.corp.intel.com> References: <1366098721-18302-1-git-send-email-nicolas.blanc@intel.com> <1366098721-18302-2-git-send-email-nicolas.blanc@intel.com> <517ABA6A.5070400@redhat.com> <388084C8C1E6A64FA36AD1D656E4856619DF0224@IRSMSX102.ger.corp.intel.com> <517EC93F.2020409@redhat.com> <388084C8C1E6A64FA36AD1D656E4856619DF0550@IRSMSX102.ger.corp.intel.com> <518A91D0.5010205@redhat.com> In-Reply-To: <518A91D0.5010205@redhat.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2013-05/txt/msg00967.txt.bz2 Hi Pedro, I just returned from vacations. Sorry for the delay. Just comparing addr_low for re-using object-files when loading a new SO mig= ht indeed be incorrect. But one may consider the current behavior of GDB as a feature, e.g.: the us= er knows something additional and want to overwrite the default mapping. So I would not change GDB. To me, the remove-symbol-file command should remove the file even if it is = currently shared because the user might have a good reason for doing this.=20 Regards, Nicolas =20 > So what is the desirable behavior for when the user does add-symbol-file = and then the program loads the same file, and then the user removes the fil= e she added. GDB drops symbols until the next DSO > event or next "sharedl= ibrary" > command invocation? The fact that GDB reuses the same file when the addr= _low happens to match looks quite brittle (it doesn't check the section off= sets (passed to add-symbol-file) are the same, for > instance). I wonder w= hether this sharing is supposed to be a valid use case, and whether it woul= dn't be better and simpler to disable it, that is, > > /* Have we already loaded this shared object? */ > ALL_OBJFILES (so->objfile) > { > if (filename_cmp (so->objfile->name, so->so_name) =3D=3D 0 > && so->objfile->addr_low =3D=3D so->addr_low >- && so->objfile->addr_low =3D=3D so->addr_low) >+ && !(so->objfile->flags & OBJF_USERLOADED)) > break; > } > >... > >- /* Unless the user loaded it explicitly, free SO's objfile. */ >- if (gdb->objfile && ! (gdb->objfile->flags & OBJF_USERLOADED) >- && !solib_used (gdb)) >- free_objfile (gdb->objfile); > > >In a way, treat manually added objfiles list and the dynamic SO list separ= ate lists. 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