From patchwork Mon Oct 1 10:32:51 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pedro Alves X-Patchwork-Id: 29595 Received: (qmail 96576 invoked by alias); 1 Oct 2018 10:32:59 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 96476 invoked by uid 89); 1 Oct 2018 10:32:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=1134, internal_error, errorsc, interpret X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 01 Oct 2018 10:32:56 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CAB402D1A4 for ; Mon, 1 Oct 2018 10:32:55 +0000 (UTC) Received: from localhost.localdomain (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6485B61352 for ; Mon, 1 Oct 2018 10:32:55 +0000 (UTC) From: Pedro Alves To: gdb-patches@sourceware.org Subject: [PATCH 2/3] Fix follow_exec latent problem Date: Mon, 1 Oct 2018 11:32:51 +0100 Message-Id: <20181001103252.5150-3-palves@redhat.com> In-Reply-To: <20181001103252.5150-1-palves@redhat.com> References: <20181001103252.5150-1-palves@redhat.com> A following commit to make each inferior have its own thread list exposes a problem with bf93d7ba99 ("Add thread after updating gdbarch when exec'ing"), which is that we can't defer adding the thread because that breaks try_open_exec_file which deep inside ends up calling inferior_thread(): #5 0x0000000000637c78 in internal_error(char const*, int, char const*, ...) (file=0xc151f8 "src/gdb/thread.c", line=165, fmt=0xc15180 "%s: Assertion `%s' failed.") at src/gdb/common/errors.c:55 #6 0x00000000008a3d80 in inferior_thread() () at src/gdb/thread.c:165 #7 0x0000000000456f91 in try_thread_db_load_1(thread_db_info*) (info=0x277eb00) at src/gdb/linux-thread-db.c:830 #8 0x0000000000457554 in try_thread_db_load(char const*, int) (library=0xb01a4f "libthread_db.so.1", check_auto_load_safe=0) at src/gdb/linux-thread-db.c:1002 #9 0x0000000000457861 in try_thread_db_load_from_sdir() () at src/gdb/linux-thread-db.c:1079 #10 0x0000000000457b72 in thread_db_load_search() () at src/gdb/linux-thread-db.c:1134 #11 0x0000000000457d29 in thread_db_load() () at src/gdb/linux-thread-db.c:1192 #12 0x0000000000457e51 in check_for_thread_db() () at src/gdb/linux-thread-db.c:1244 #13 0x0000000000457ed2 in thread_db_new_objfile(objfile*) (objfile=0x270ff60) at src/gdb/linux-thread-db.c:1273 #14 0x000000000045a92e in std::_Function_handler::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7ffef3efe140: 0x270ff60) at /usr/include/c++/7/bits/std_function.h:316 #15 0x00000000007bbebf in std::function::operator()(objfile*) const (this=0x24e1d18, __args#0=0x270ff60) at /usr/include/c++/7/bits/std_function.h:706 #16 0x00000000007bba86 in gdb::observers::observable::notify(objfile*) const (this=0x117ce80 , args#0=0x270ff60) at src/gdb/common/observable.h:106 #17 0x0000000000856000 in symbol_file_add_with_addrs(bfd*, char const*, symfile_add_flags, section_addr_info*, objfile_flags, objfile*) (abfd=0x1d7dae0, name=0x254bfc0 "/ho The problem is latent currently because inferior_thread() at that point manages to return a thread, even though it's the wrong one (of the old inferior). The problem originally fixed by bf93d7ba99 was: (...) we should avoid doing register reads after a process does an exec and before we've updated that inferior's gdbarch. Otherwise, we may interpret the registers using the wrong architecture. (...) The call to "add_thread" done just after adding the inferior is problematic, because it ends up reading the registers (because the ptid is re-used, we end up doing a switch_to_thread to it, which tries to update stop_pc). (...) The register-reading issue is no longer a problem nowadays, ever since switch_to_thread stopped reading the stop_pc in git commit f2ffa92bbce9 ("gdb: Eliminate the 'stop_pc' global"). So this commit basically reverts bf93d7ba99. gdb/ChangeLog: yyyy-mm-dd Pedro Alves * infrun.c (follow_exec) : Add thread and switch to it before calling into try_open_exec_file. --- gdb/infrun.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/gdb/infrun.c b/gdb/infrun.c index f1cd85c8ec..3ddb231ffe 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -1200,6 +1200,7 @@ follow_exec (ptid_t ptid, char *exec_file_target) set_current_inferior (inf); set_current_program_space (inf->pspace); + add_thread (ptid); } else { @@ -1229,11 +1230,6 @@ follow_exec (ptid_t ptid, char *exec_file_target) registers. */ target_find_description (); - /* The add_thread call ends up reading registers, so do it after updating the - target description. */ - if (follow_exec_mode_string == follow_exec_mode_new) - add_thread (ptid); - solib_create_inferior_hook (0); jit_inferior_created_hook ();