From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1809 invoked by alias); 28 May 2012 14:27:50 -0000 Received: (qmail 1788 invoked by uid 22791); 28 May 2012 14:27:47 -0000 X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_BJ X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 28 May 2012 14:27:33 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id D6CD81C69FE; Mon, 28 May 2012 10:27:32 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id leVuCp0aMGaJ; Mon, 28 May 2012 10:27:32 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id A8E4B1C6A5B; Mon, 28 May 2012 10:27:31 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 452AE145616; Mon, 28 May 2012 07:27:27 -0700 (PDT) Date: Mon, 28 May 2012 14:27:00 -0000 From: Joel Brobecker To: Jan Kratochvil 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: <20120528142727.GH5492@adacore.com> References: <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> <20120518164815.GA11883@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120518164815.GA11883@host2.jankratochvil.net> User-Agent: Mutt/1.5.20 (2009-06-14) 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/msg00991.txt.bz2 > 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. I just want to make sure that we do not get carried away trying to implement the perfect solution, because I don't have the time in the next few weeks to implement it, and I don't even know how to do that at the moment. What I am trying to do is to fix the regression that you observed in the Fortran testsuite, which somewhat also affects all languages as well. > > + 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. You have to start with the MAINLINE objfiles first, as you demonstrated with your Fortran program. What the code above does, in practice, is trying to go through the ALL_OBJFILES list in the same order as before, except that we try the "context" objfile file first. But, to make things even more interesting, having a "context" objfile does not mean that it should be checked ahead of any MAINLINE objfile, because otherwise we break your Fortran test. Another way of expressing the intent of my patch is to say: Try the "context" objfile first, unless it's not a MAINLINE objfile, in which case we try the MAINLINE objfiles, and then our "context" objfile. > 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. Actually, I prefer target-dependent, since I showed that it is not wrong for x86-windows. I definitely feel like I've opened a can of worms that I will not have time and energy to fix (actual linking behavior is target dependent, and getting the correct search order is also target dependent). This was also meant as a cheap improvement while I work on extending the expression parser(s) [I plan on enhancing C and Ada only, not the other languages] So, we have two options, at this point: (1) Revert my original patch; (2) Enhance the heuristics in my patch. This second patch is an attempt at this. I think it would be a loss to revert, but if we cannot converge on the heuristics for the search, then we'll just go to the previous search order (which may also be arbitrary in some ways). In the end, I think the current heuristics are not perfect but more helpful in some situations, without hopefully be worse for some other situations. If we can't agree on that, then I think the best option at this point is to revert my patch, as it obviously had some unintended and unwanted side effects. Which way do we want to go? -- Joel PS: Just a reminder that we are also potentially one week away from branching.