From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58277 invoked by alias); 7 Feb 2020 20:18:46 -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 58264 invoked by uid 89); 7 Feb 2020 20:18:46 -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=wild, HX-Received:1012, H*c:alternative, gdbsum X-HELO: mail-wr1-f65.google.com Received: from mail-wr1-f65.google.com (HELO mail-wr1-f65.google.com) (209.85.221.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Feb 2020 20:18:36 +0000 Received: by mail-wr1-f65.google.com with SMTP id y17so394935wrh.5 for ; Fri, 07 Feb 2020 12:18:35 -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=ot67sfmI1lcNlXmDgwp9QgL+q7v8k3QdWLdfPp1c1Xw=; b=DoG/RLYIpSSX3gOu6Nc5/l+Z8RpZ1VPwPiOH7wmb61CX97f1DZsSTbdOS27gqK2Cht gbgVpsOR2Qv1fczHfg8xxWzzVu92saCOQke49ePs9MnyHJ1n/v1BibbNwlahstShu4UN p2wSep1uc7XJOZTlF1a0LihfWCu/L+s3QY7joJZ47uf6BKuUte9uCUcL1H9BtvQEtY9s +2NVRzgsyKAFyMu77Rsqx/eKphsASmJrUwkL5gdr7kARDPNvc2MHNzX9HEOMdDNAtzFG hwVMd5AbnIyGpS8UNBh24NZsRZOrGOYhOvgLkHQcU4mpSS2swgoM+usC6xODJLTlRwQm qvBw== 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: <87sgjm6un4.fsf@redhat.com> From: Luis Machado Date: Fri, 07 Feb 2020 20:18: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/msg00183.txt.bz2 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. > 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/ > >