From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44197 invoked by alias); 7 Feb 2020 20:11:56 -0000 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 Received: (qmail 44182 invoked by uid 89); 7 Feb 2020 20:11:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy= X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (205.139.110.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Feb 2020 20:11:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581106312; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=o6O5rBTuhB6iuK7WmVL0pVDj0w7MpwAV4dlAy4EGLxs=; b=PYRt05eFtvCa4bfCnegyJT3IPgt+MFFxbdzZDtJGxmwRJp173LqVgfazB1c8Z2WfbksTYs BxeYO0NvZoX2Zr/x2YP8x4FLqUDEospZVKx/LxO9Vm9g6FENBkhtOKzfClSD989Tl1/joF MNr65FcxEEBhYxz/95zzRbWqC1Gdsw4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-118-pHgiT1LMNDOO18ogyoww3w-1; Fri, 07 Feb 2020 15:11:48 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7B42D800D5C; Fri, 7 Feb 2020 20:11:47 +0000 (UTC) Received: from localhost (unused-10-15-17-196.yyz.redhat.com [10.15.17.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4C65160BEC; Fri, 7 Feb 2020 20:11:47 +0000 (UTC) From: Sergio Durigan Junior To: Andrew Burgess Cc: Luis Machado , GDB Patches Subject: Re: [PATCH] New testcase for PR tui/25126 (staled source cache) References: <20200206225943.26709-1-sergiodj@redhat.com> <4a3db909-8677-fb84-39cf-84495266fdd8@linaro.org> <20200207114712.GI4020@embecosm.com> <87sgjm9vf7.fsf@redhat.com> <87sgjm6un4.fsf@redhat.com> Date: Fri, 07 Feb 2020 20:11:00 -0000 In-Reply-To: <87sgjm6un4.fsf@redhat.com> (Sergio Durigan Junior's message of "Fri, 07 Feb 2020 14:54:07 -0500") Message-ID: <87o8ua6ttp.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00182.txt.bz2 On Friday, February 07 2020, I wrote: > On Friday, February 07 2020, I wrote: > >> On Friday, February 07 2020, Andrew Burgess wrote: >>> I'm not suggesting that you need to track down the cause of this >>> issue, but I agree with Luis that we should avoid arbitrary short >>> pauses. >>> >>> I think you could probably use gdb_get_line_number to solve this >>> problem, something like this completely untested code: >>> >>> # In some cases it has been observed that the file-system doesn't >>> # immediately reflect the rename. Here we wait for the file to >>> # reflect the expected new contents. >>> proc wait_for_rename {} { >>> global srcfile >>> for { set i 0 } { $i < 5 } { incr i } { >>> if { ![catch { gdb_get_line_number \ >>> "pattern only matching the new line" \ >>> ${srcfile} }] } { >>> return >>> } >>> sleep 1 >>> } >>> error "file failed to rename correctly" >>> } >> >> Ah, cool. I'll adjust that to the code. Thank you. > > OK, after trying your code, I can say that the problem is not on TCL. > wait_for_rename returns successfully, and I've checked that > gdb_get_line_number returns the correct value for the line. So, for > TCL, the rename succeeded. > > Here's an interesting thing: I put a gdb_interact after the second "run" > command, and then did: > > (gdb) list > 35 printf ("hello\n"); /* break-here */ > (gdb) shell gdb.=20=20=20=20=20 > gdb.log gdb.sum=20=20 > (gdb) shell outputs/gdb.base/cached-source-file/cached-source-file > foo > hello > > See how, for GDB, the inferior doesn't have the 'printf ("foo\n");' > line, but when I run it externally I can see "foo" being printed? This > means that GCC compiled the correct file, but GDB did not load it again, > somehow. > > I find it extremely interesting how putting a "sleep 1" after the rename > magically solves this problem. I would be less intrigued if we had to > put "sleep 1" after "gdb_compile", because then it would hint at some > race condition happening with GCC and GDB (very unlikely, but easier to > understand). > > I didn't want to, but I guess I'll have to keep investigating this. > Unless you (or someone) have any other ideas. I think I found the issue. On symfile.c:reread_symbols, the check performed to see whether the new objfile being loaded is different than the previous one is based on calling 'stat' and checking 'st_mtime': ... new_modtime =3D new_statbuf.st_mtime; if (new_modtime !=3D objfile->mtime) { printf_filtered (_("`%s' has changed; re-reading symbols.\n"), objfile_name (objfile)); ... According to stat(2), 'st_mtime' is actually 'st_mtim.tv_sec', which means the precision of this field is given in seconds. Since Linux 2.6 'st_mtim's precision is given in nanoseconds, but we still use the seconds field. Because the testing script runs so fast, it's really likely that the old and the new files will have the same 'st_mtime'. Here's the output of an 'fprintf' I put in the code: new_modtime =3D 1581105949, old_modtime =3D 1581105949 So yeah, we have a few options here: 1) For now, I think it's justifiable to use "sleep 1" in the code, to force 'st_mtime' to be different between the two files. 2) The GDB code could be modernized to use nanosecond precision, which should solve this problem. Thanks, --=20 Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/