From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78615 invoked by alias); 8 Feb 2020 09:42:50 -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 78599 invoked by uid 89); 8 Feb 2020 09:42:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*c:alternative, gdbsum, gdb.sum, UD:gdb.sum X-HELO: mail-wm1-f48.google.com Received: from mail-wm1-f48.google.com (HELO mail-wm1-f48.google.com) (209.85.128.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 08 Feb 2020 09:42:47 +0000 Received: by mail-wm1-f48.google.com with SMTP id p17so5327971wma.1 for ; Sat, 08 Feb 2020 01:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gOU+EdOmGNxzBoOkfm4QlwvA7L1Cn9QCkIQzLmwfukg=; b=fnoAmmmNKjG4iCt8yIz2vmQuw3/7DB+KbBLoy/sV3+lpQKqZx36RDonKTO6Thr9TxB 7uVEFc1tK/PNG6D0iWFy7xDXkftWo5vg5Y0+pns0Vn6PuLE4nSBF58S54SVMf57edeLy g1HtoxN0pglBu1mHcXzi8teSvgTckgG4khNCqF9pO1VBmg0BlJ7njUNVPl4bTSO6d3Eq HdFztWBfOX5acx0n5ziRfPTth2/eOqYHuejfGwkcsIsDNxiH2F864pXdRaqQPp9G5B4W EBzfcto54iwYZqCzygq1ZXYw/JkftetNGDo2R1ZBJIccjwZYgb+dvIANY93ozjA2H4H8 dctQ== MIME-Version: 1.0 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> In-Reply-To: From: Luis Machado Date: Sat, 08 Feb 2020 09:42:00 -0000 Message-ID: Subject: Re: [PATCH] New testcase for PR tui/25126 (staled source cache) To: Sergio Durigan Junior Cc: Andrew Burgess , GDB Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00206.txt.bz2 On Fri, 7 Feb 2020 at 17:18, Luis Machado wrote: > > > On Fri, Feb 7, 2020, 20:54 Sergio Durigan Junior > 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. >> gdb.log gdb.sum >> (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. >> > > Wild guess... Is the operation of renaming and reloading back in gdb > executing quickly enough that the bfd cache doesn't notice a change (lack > of timestamp precision in the filesystem)? This is assuming the object file > is the same between loads. > Heh... Nevermind. I noticed you found out something similar a few minutes before i replied. I ran into this a while ago with GCC's testsuite. It uses repeated names for some files and sometimes the object files are the same, so things may not get updated properly in GDB. > > >> Thanks, >> >> -- >> Sergio >> GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 >> Please send encrypted e-mail if possible >> http://sergiodj.net/ >> >>