From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 757573857820; Fri, 29 Jul 2022 13:46:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 757573857820 From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug mi/29426] FAIL: gdb.mi/mi-var-invalidate.exp: linteger not anymore in scope due to binary changes (unexpected output) Date: Fri, 29 Jul 2022 13:46:21 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: mi X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2022 13:46:21 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29426 --- Comment #7 from Tom de Vries --- (In reply to Lancelot SIX from comment #6) > Hi >=20 > This is what I also see. TBH, I am really wondering why I have not seen > with my testing and with my ubuntu boxes. >=20 It's PIE vs. no-PIE (and not for the first time ;) ). So my system has no-PIE by default (because I haven't installed the gcc-PIE package). Using target board unix/-fPIE/-pie (case PIE), the test passes. Using unix (case no-PIE), it fails. On ubuntu, there's a PIE default for system gcc. When you build gcc from scratch, it probably had no-PIE default instead. Anyway, in one case (no-PIE) var_create succeeds, in the other (PIE) not. So, varobj_create calls get_frame_block, which calls block_for_pc, with a relocated pc. Then block_for_pc calls block_for_pc_sect, which call blockvector_for_pc_sect, which calls find_pc_sect_compunit_symtab, which ca= lls objf->find_pc_sect_compunit_symtab with objf =3D=3D mi-var-invalidate_bis. In the PIE case, this query returns null because we try to find an relocated address in an unrelocated objfile. In the no-PIE case, this query returns non-null because we try to find an non-relocatable address in an non-relocatable objfile. In the PIE case > I am working on a fix for this. >=20 > Thanks for taking the time and looking into it. --=20 You are receiving this mail because: You are on the CC list for the bug.=