From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1638 invoked by alias); 28 May 2012 16:12:34 -0000 Received: (qmail 1627 invoked by uid 22791); 28 May 2012 16:12:33 -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; Mon, 28 May 2012 16:12:18 +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 q4SGC5dM006581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 May 2012 12:12:05 -0400 Received: from host2.jankratochvil.net (ovpn-116-47.ams2.redhat.com [10.36.116.47]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q4SGC1Jp017835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 28 May 2012 12:12:03 -0400 Date: Mon, 28 May 2012 16:12: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: <20120528161200.GA19230@host2.jankratochvil.net> References: <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> <20120528142727.GH5492@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120528142727.GH5492@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/msg00994.txt.bz2 On Mon, 28 May 2012 16:27:27 +0200, Joel Brobecker wrote: > 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. I somehow also share this approach currently. > 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. Just the MAINLINE exception is not enough, it still regresses GDB: ==> 50.c <== //extern int v; extern int f (void); extern int g (void); int main (void) { return 10 * f () + g (); } ==> 50l.c <== int v=1; int f (void) { return v; } ==> 50ll.c <== int v=2; int g (void) { return v; } ============== gcc -o 50l.so 50l.c -Wall -g -shared -fPIC;gcc -o 50ll.so 50ll.c -Wall -g -shared -fPIC;gcc -o 50a 50.c -Wall -g ./50l.so ./50ll.so;gcc -o 50b 50.c -Wall -g ./50ll.so ./50l.so;./50a;echo $?;./50b;echo $? for e in 50a 50b;do ./$e;echo $?;./gdb -q ./$e -ex 'b f' -ex 'b g' -ex r -ex 'p v' -ex c -ex 'p v' -ex c -ex q;done before your patches (and therefore matching GDB the inferior behavior): 11 $1 = 1 $2 = 1 22 $1 = 2 $2 = 2 with your final patches (undo the first, apply this WIP second patch) 11 $1 = 1 $2 = 2 22 $1 = 1 $2 = 2 GDB is just behaving right in normal cases. GDB is not correct, that it does not correctly maintain objfiles order in the case of some dlopens/dlcloses (at least I guess so, I did not try to reproduce). > 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. But '"context" objfile first' is incompatible with SVR4. The behavior apparently has to be target specific. > 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). Not sure what do you call 'heuristics' but as long as it becomes target dependent the patch should be simple. Thanks, Jan