This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] New testcase for PR tui/25126 (staled source cache)
On Fri, 7 Feb 2020 at 17:18, Luis Machado <luis.machado@linaro.org> wrote:
>
>
> On Fri, Feb 7, 2020, 20:54 Sergio Durigan Junior <sergiodj@redhat.com>
> 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/
>>
>>