From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7567 invoked by alias); 18 May 2012 17:46:29 -0000 Received: (qmail 7450 invoked by uid 22791); 18 May 2012 17:46:27 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,TW_BJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 May 2012 17:46:14 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4IHjqjL031131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 May 2012 13:45:52 -0400 Received: from host2.jankratochvil.net (ovpn-116-17.ams2.redhat.com [10.36.116.17]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q4IGmGRS014732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 18 May 2012 12:48:18 -0400 Date: Fri, 18 May 2012 17:46:00 -0000 From: Jan Kratochvil To: Joel Brobecker Cc: Pedro Alves , Tom Tromey , gdb-patches@sourceware.org Subject: Re: RFC for: "Re: Regression for gdb.fortran/library-module.exp [Re: [RFA] choose symbol from given block's objfile first.]" Message-ID: <20120518164815.GA11883@host2.jankratochvil.net> References: <874nrqvbeh.fsf@fleche.redhat.com> <20120509190529.GI15555@adacore.com> <20120511072606.GA25458@host2.jankratochvil.net> <20120514143927.GB10253@adacore.com> <20120514145151.GA30451@host2.jankratochvil.net> <4FB1459E.60208@redhat.com> <20120514175913.GM10253@adacore.com> <20120514180624.GA16368@host2.jankratochvil.net> <20120515130851.GP10253@adacore.com> <20120516195718.GA10253@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120516195718.GA10253@adacore.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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: 2012-05/txt/msg00701.txt.bz2 On Wed, 16 May 2012 21:57:18 +0200, Joel Brobecker wrote: > --- a/gdb/objfiles.c > +++ b/gdb/objfiles.c [...] > +void > +iterate_over_objfiles_in_search_order > + (iterate_over_objfiles_in_search_order_cb cb, > + void *cb_data, > + struct objfile *context_objfile) > +{ > + int stop = 0; > + struct objfile *objfile; > + > + if (context_objfile && context_objfile->flags & OBJF_MAINLINE) > + { > + stop = cb (context_objfile, cb_data); > + if (stop) > + return; > + } > + > + ALL_OBJFILES (objfile) > + { > + if (objfile->flags & OBJF_MAINLINE && objfile != context_objfile) > + { > + stop = cb (objfile, cb_data); > + if (stop) > + return; > + } > + } I see a bit problem this function is objfile based and not solib based, as the solib order from svr4_current_sos() is completely lost here. That is if we have two shared libraries with global variable X ld.so defines which one gets used depending on their dlopen order. so_list_head already has wrong order due to update_solib_list. Maybe update_solib_list should be fixed to keep both so_list_head order and also properly ensure matching objfiles order. If someone does some add-symbol-file by hand the order gets lost anyway. Maybe we could ensure just so_list_head order, place this "correct order search" to elf_lookup_lib_symbol and fall back to the old unfixed objfiles search in arbitrary order to keep add-symbol-file working. Sure there should be some exceptions for hidden symbols but this should be implementable on top of your CONTEXT_OBJFILE being there probably for this purpose. Plus weak symbols. > + > + if (context_objfile && !(context_objfile->flags & OBJF_MAINLINE)) > + { > + stop = cb (context_objfile, cb_data); > + if (stop) > + return; > + } > + > + ALL_OBJFILES (objfile) > + { > + if (!(objfile->flags & OBJF_MAINLINE) && objfile != context_objfile) > + { > + stop = cb (objfile, cb_data); > + if (stop) > + return; > + } > + } > +} I do not see why to use the OBJF_MAINLINE exceptions here. I see the correct order is just the most simple ALL_OBJFILES loop. Maybe you could re-state the case you were trying to fix as your testcase gdb.base/print-file-var.exp false PASS [Re: [RFA] choose symbol from given block's objfile first.] http://sourceware.org/ml/gdb-patches/2012-05/msg00692.html is wrong. address_info ("info addr") function is wrong but it does not apply for "print". Thanks, Jan