From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 5F75238582A1 for ; Sat, 16 Sep 2023 10:18:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5F75238582A1 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1694859519; 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=GyQSEz+iett/t5842KFtqg8Mo9gXDAYT4uXzrLCrbrc=; b=fW8+7QuOM0lxSoGnA0OA/d4g5PWMBHc/uLRY57MRNgV8aGNf7tGHgM38PNU0DYXqXNvTp5 m/+j3rKQh95neKTe/y/oA1ONIGWy6spwHMA55hn869DPBe/eC9tt1iplKWz0f5hVpWd1v3 dTwB2Wx4BUwQUtUNWsnrpfjQFNR0VRQ= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-462-JKQa6uT6OXuYmUjf4xn73w-1; Sat, 16 Sep 2023 06:18:37 -0400 X-MC-Unique: JKQa6uT6OXuYmUjf4xn73w-1 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-30e3ee8a42eso1952949f8f.1 for ; Sat, 16 Sep 2023 03:18:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694859515; x=1695464315; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GyQSEz+iett/t5842KFtqg8Mo9gXDAYT4uXzrLCrbrc=; b=Yaz5CrphPE5LRYOn9ir69lOk/n0HjZM9Rd5E9BuVH8xXJiIRCuWxbSqdNiFSLZBYLc pjdNnuMzaQ6Jmf33Nlu66rUyJUEUUuRaqdjkF+PUZTIEeREaHgplg+L2UiJDv/UxxC/9 1xIBkzc+tEKWbTzB4LTgpWgFKqbIB6CfY+xNgGiA2m7ZuT7fx6bRTRmSma4e8K+7qptx LgXFIRdTOWdjOTF5/ITdrVi2oV3MErIS0BBRZOGnDcEnc0fnoFNRCIELjl48O7QtSGLq 3mYJ3sXWpC5pxt9c4xPUjukSwlbchJBPFb+4C/j8xBfB4YV2ppNWWIqiT6TSejrdiM/F /KlQ== X-Gm-Message-State: AOJu0Yzmg2ujy9PrZvsA9OS4wTH4XFd9/deeW4nMaKLN7Om0Tc4pkFJx G9LjT4OwZ+csvRzs1kQpDDfvBCwcdzrnmzkJZiFN7JPJSiXoik+Xs5RRtJxgqoJCx06P25cFb+l yx3Sy89TLT2jQJ4T8Y16GpSwNxM1C4kQAczI2Jj9Y8SiaozTNAGTq4xLKFDEQ/AI7nuuj/6kRMn rlgQ3Wkg== X-Received: by 2002:adf:e9c6:0:b0:31c:e933:9590 with SMTP id l6-20020adfe9c6000000b0031ce9339590mr3309615wrn.33.1694859515711; Sat, 16 Sep 2023 03:18:35 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE87UEKyPGQJS+uPWgV73OGK2ag8mIxON5gIrN28nShcWMZDr4/EoWVyrqHPzTi1qre84Vj1w== X-Received: by 2002:adf:e9c6:0:b0:31c:e933:9590 with SMTP id l6-20020adfe9c6000000b0031ce9339590mr3309601wrn.33.1694859515353; Sat, 16 Sep 2023 03:18:35 -0700 (PDT) Received: from localhost (92.40.218.107.threembb.co.uk. [92.40.218.107]) by smtp.gmail.com with ESMTPSA id l26-20020a056000023a00b0031ff1ef7dc0sm3942081wrz.66.2023.09.16.03.18.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 16 Sep 2023 03:18:34 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCH 9/9] gdb: use reopen_exec_file from reread_symbols Date: Sat, 16 Sep 2023 11:18:10 +0100 Message-Id: X-Mailer: git-send-email 2.25.4 In-Reply-To: References: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This commit fixes an issue that was discovered while writing the tests for the previous commit. I noticed that, when GDB restarts an inferior, the executable_changed event would trigger twice. The first notification would originate from: #0 exec_file_attach (filename=0x4046680 "/tmp/hello.x", from_tty=0) at ../../src/gdb/exec.c:513 #1 0x00000000006f3adb in reopen_exec_file () at ../../src/gdb/corefile.c:122 #2 0x0000000000e6a3f2 in generic_mourn_inferior () at ../../src/gdb/target.c:3682 #3 0x0000000000995121 in inf_child_target::mourn_inferior (this=0x2fe95c0 ) at ../../src/gdb/inf-child.c:192 #4 0x0000000000995cff in inf_ptrace_target::mourn_inferior (this=0x2fe95c0 ) at ../../src/gdb/inf-ptrace.c:125 #5 0x0000000000a32472 in linux_nat_target::mourn_inferior (this=0x2fe95c0 ) at ../../src/gdb/linux-nat.c:3609 #6 0x0000000000e68a40 in target_mourn_inferior (ptid=...) at ../../src/gdb/target.c:2761 #7 0x0000000000a323ec in linux_nat_target::kill (this=0x2fe95c0 ) at ../../src/gdb/linux-nat.c:3593 #8 0x0000000000e64d1c in target_kill () at ../../src/gdb/target.c:924 #9 0x00000000009a19bc in kill_if_already_running (from_tty=1) at ../../src/gdb/infcmd.c:328 #10 0x00000000009a1a6f in run_command_1 (args=0x0, from_tty=1, run_how=RUN_STOP_AT_MAIN) at ../../src/gdb/infcmd.c:381 #11 0x00000000009a20a5 in start_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:527 #12 0x000000000068dc5d in do_simple_func (args=0x0, from_tty=1, c=0x35c7200) at ../../src/gdb/cli/cli-decode.c:95 While the second originates from: #0 exec_file_attach (filename=0x3d7a1d0 "/tmp/hello.x", from_tty=0) at ../../src/gdb/exec.c:513 #1 0x0000000000dfe525 in reread_symbols (from_tty=1) at ../../src/gdb/symfile.c:2517 #2 0x00000000009a1a98 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_STOP_AT_MAIN) at ../../src/gdb/infcmd.c:398 #3 0x00000000009a20a5 in start_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:527 #4 0x000000000068dc5d in do_simple_func (args=0x0, from_tty=1, c=0x35c7200) at ../../src/gdb/cli/cli-decode.c:95 In the first case the call to exec_file_attach first passes through reopen_exec_file. The reopen_exec_file performs a modification time check on the executable file, and only calls exec_file_attach if the executable has changed on disk since it was last loaded. However, in the second case things work a little differently. In this case GDB is really trying to reread the debug symbol. As such, we iterate over the objfiles list, and for each of those we check the modification time, if the file on disk has changed then we reload the debug symbols from that file. However, there is an additional check, if the objfile has the same name as the executable then we will call exec_file_attach, but we do so without checking the cached modification time that indicates when the executable was last reloaded, as a result, we reload the executable twice. In this commit I propose that reread_symbols be changed to unconditionally call reopen_exec_file before performing the objfile iteration. This will ensure that, if the executable has changed, then the executable will be reloaded, however, if the executable has already been recently reloaded, we will not reload it for a second time. After handling the executable, GDB can then iterate over the objfiles list and reload them in the normal way. With this done I now see the executable reloaded only once when GDB restarts an inferior, which means I can remove the kfail that I added to the gdb.python/py-exec-file.exp test in the previous commit. --- gdb/symfile.c | 18 +++++------------- gdb/testsuite/gdb.python/py-exec-file.exp | 5 ----- 2 files changed, 5 insertions(+), 18 deletions(-) diff --git a/gdb/symfile.c b/gdb/symfile.c index 43fd45c4050..fac8ec19a22 100644 --- a/gdb/symfile.c +++ b/gdb/symfile.c @@ -2457,11 +2457,10 @@ remove_symbol_file_command (const char *args, int from_tty) void reread_symbols (int from_tty) { - long new_modtime; - struct stat new_statbuf; - int res; std::vector new_objfiles; + reopen_exec_file (); + for (objfile *objfile : current_program_space->objfiles ()) { if (objfile->obfd.get () == NULL) @@ -2475,6 +2474,8 @@ reread_symbols (int from_tty) `ar', often called a `static library' on most systems, though a `shared library' on AIX is also an archive), then you should stat on the archive name, not member name. */ + int res; + struct stat new_statbuf; if (objfile->obfd->my_archive) res = stat (bfd_get_filename (objfile->obfd->my_archive), &new_statbuf); else @@ -2486,7 +2487,7 @@ reread_symbols (int from_tty) objfile_name (objfile)); continue; } - new_modtime = new_statbuf.st_mtime; + long new_modtime = new_statbuf.st_mtime; if (new_modtime != objfile->mtime) { gdb_printf (_("`%ps' has changed; re-reading symbols.\n"), @@ -2508,15 +2509,6 @@ reread_symbols (int from_tty) /* We need to do this whenever any symbols go away. */ clear_symtab_users_cleanup defer_clear_users (0); - if (current_program_space->exec_bfd () != NULL - && filename_cmp (bfd_get_filename (objfile->obfd.get ()), - bfd_get_filename (current_program_space->exec_bfd ())) == 0) - { - /* Reload EXEC_BFD without asking anything. */ - - exec_file_attach (bfd_get_filename (objfile->obfd.get ()), 0); - } - /* Keep the calls order approx. the same as in free_objfile. */ /* Free the separate debug objfiles. It will be diff --git a/gdb/testsuite/gdb.python/py-exec-file.exp b/gdb/testsuite/gdb.python/py-exec-file.exp index 5ad3cd7e50f..7aa19a867d7 100644 --- a/gdb/testsuite/gdb.python/py-exec-file.exp +++ b/gdb/testsuite/gdb.python/py-exec-file.exp @@ -190,11 +190,6 @@ with_test_prefix "exec changes on disk" { runto_main - # There is currently an issue where the executable_changed event - # will trigger twice during an inferior restart. This should be - # fixed in the next commit, at which point this kfail can be - # removed. - setup_kfail "????" *-*-* check_exec_change [string_to_regexp $binfile1] True \ "check executable_changed state after exec changed on disk" } -- 2.25.4