From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7016 invoked by alias); 18 May 2012 17:37:30 -0000 Received: (qmail 6889 invoked by uid 22791); 18 May 2012 17:37: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:37:11 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4IHanLw022376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 May 2012 13:36:49 -0400 Received: from host2.jankratochvil.net (ovpn-116-17.ams2.redhat.com [10.36.116.17]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q4IHagH3020985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 18 May 2012 13:36:45 -0400 Date: Fri, 18 May 2012 17:37:00 -0000 From: Jan Kratochvil To: Joel Brobecker Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: gdb.base/print-file-var.exp false PASS [Re: [RFA] choose symbol from given block's objfile first.] Message-ID: <20120518173642.GA12978@host2.jankratochvil.net> References: <1336430581-11262-1-git-send-email-brobecker@adacore.com> <874nrqvbeh.fsf@fleche.redhat.com> <20120509190529.GI15555@adacore.com> <20120509190753.GA31769@adacore.com> <20120509214758.GQ15555@adacore.com> <20120509214856.GA8314@adacore.com> <20120518161008.GA24465@host2.jankratochvil.net> <20120518171708.GM10253@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120518171708.GM10253@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/msg00698.txt.bz2 On Fri, 18 May 2012 19:17:08 +0200, Joel Brobecker wrote: > I really don't know how to read your last sentence, and I am going to > pretend you did not write it. Please correct me if I misunderstood > what you are trying to imply. I think it is clear that if GDB commands prints value X of variable Y then the inferior program (either running standalone or under GDB) should also evaluate variable Y as value X. $ gdb.base/print-file-var-main ;echo $? 0 Therefore inferior sees 'print-file-var-lib2.c'::this_version_id as 104 > > > + if (get_version_2 () != 104) > > > + return 2; as otherwise the executable would return 2 (and not 0). But GDB PASSes if 'print-file-var-lib2.c'::this_version_id is read as 203. I do not understand this discrepancy between print-file-var.exp and print-file-var-main.c. > On the other hand, on Windows, with the same code, the function > returns 203. So the code is not portable. I did not remember the MS-Windows platform behavior (Pedro has stated it). In such case this program returns code 2 (and not 0) on MS-Windows? > I wonder how things are working on GNU/Linux, because the two shared > libraries are linked independently, and then the main executable > does not reference the global variable at all. As the libraries are build with -fPIC they use .got references: 0000000000000670 : [...] 674: 48 8b 05 95 02 20 00 mov 0x200295(%rip),%rax # 200910 <_DYNAMIC+0x1e0> 67b: 8b 00 mov (%rax),%eax Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al [22] .data PROGBITS 0000000000200950 000950 000004 00 WA 0 0 4 [20] .got PROGBITS 0000000000200900 000900 000030 08 WA 0 0 8 Relocation section '.rela.dyn' at offset 0x450 contains 9 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 0000000000200910 0000000d00000006 R_X86_64_GLOB_DAT 0000000000200950 this_version_id + 0 - in .got Symbol table '.dynsym' contains 14 entries: Num: Value Size Type Bind Vis Ndx Name 13: 0000000000200950 4 OBJECT GLOBAL DEFAULT 22 this_version_id - in .data And therefore for the first library ld.so resolves the .got reference into itself but for the second library the .got reference points to the first library's variable. > I don't know what to do. I can remove the testcase entirely, or > we can test the target and adjust the expected output based on > that. I think it depends how complete/good fix ends up checked in GDB. > This is still not going to help with the GDB side of things. But > I don't think that this is a regression. I don't think we have any > way of knowing which instance of the variable to pick. This check-in regressed the C example from: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40040 cat >clib.c <cmain.c <