From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id AjCqKmqApmDjXQAAWB0awg (envelope-from ) for ; Thu, 20 May 2021 11:29:46 -0400 Received: by simark.ca (Postfix, from userid 112) id A707B1F11C; Thu, 20 May 2021 11:29:46 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=MAILING_LIST_MULTI, RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 226AE1E813 for ; Thu, 20 May 2021 11:29:45 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A0F7A38515E9; Thu, 20 May 2021 15:29:44 +0000 (GMT) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 91D46385E007 for ; Thu, 20 May 2021 15:29:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 91D46385E007 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tdevries@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 9D93FAB7C for ; Thu, 20 May 2021 15:29:41 +0000 (UTC) Date: Thu, 20 May 2021 17:29:40 +0200 From: Tom de Vries To: gdb-patches@sourceware.org Subject: [PATCH][gdb/breakpoint] Fix assert in jit_event_handler Message-ID: <20210520152938.GA31635@delia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" Hi, Consider a minimal test-case test.c: ... int main (void) { return 0; } ... which we can compile into llvm byte code using clang: ... $ clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf test.c ... and then run using lli, which uses the llvm jit: ... $ lli test.ll ... If we run this under gdb, we run into an assert: ... $ gdb -q -batch -ex run --args /usr/bin/lli test.ll Dwarf Error: Cannot not find DIE at 0x18a936e7 \ [from module libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". src/gdb/jit.c:1178: internal-error: \ void jit_event_handler(gdbarch*, objfile*): \ Assertion `jiter->jiter_data != nullptr' failed. ... This is caused by the following. When running jit_breakpoint_re_set_internal, we first handle libLLVM.so.10.debug, and set a jit breakpoint. Next we handle libLLVM.so.10: ... (gdb) p the_objfile.original_name $42 = 0x2494170 "libLLVM.so.10" ... but the minimal symbols we find are from libLLVM.so.10.debug: ... (gdb) p reg_symbol.objfile.original_name $43 = 0x38e7c50 "libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug" (gdb) p desc_symbol.objfile.original_name $44 = 0x38e7c50 "libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug" ... and consequently, the objf_data is the one from libLLVM.so.10.debug: ... jiter_objfile_data *objf_data = get_jiter_objfile_data (reg_symbol.objfile); ... and so we hit this: ... if (objf_data->cached_code_address == addr) continue; ... and no second jit breakpoint is inserted. Subsequently, the jit breakpoint is triggered and handled, but when finding the symbol for the breakpoint address we get: ... (gdb) p jit_bp_sym.objfile.original_name $52 = 0x2494170 "libLLVM.so.10" ... The assert 'jiter->jiter_data != nullptr' triggers because it checks libLLVM.so.10 while the one with jiter_data setup is libLLVM.so.10.debug. This fixes the assert: ... jiter_objfile_data *objf_data - = get_jiter_objfile_data (reg_symbol.objfile); - = get_jiter_objfile_data (the_objfile); ... but consequently we'll have two jit breakpoints, so we also make sure we don't set a jit breakpoint on separate debug objects like libLLVM.so.10.debug. Tested on x86_64-linux. Any comments? Thanks, - Tom [gdb/breakpoint] Fix assert in jit_event_handler gdb/ChangeLog: 2021-05-20 Tom de Vries PR breakpoint/27889 * jit.c (jit_breakpoint_re_set_internal): Skip separate debug objects. Call get_jiter_objfile_data with the_objfile. --- gdb/jit.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/gdb/jit.c b/gdb/jit.c index 296b436c796..be10f197fd6 100644 --- a/gdb/jit.c +++ b/gdb/jit.c @@ -807,6 +807,10 @@ jit_breakpoint_re_set_internal (struct gdbarch *gdbarch, program_space *pspace) { for (objfile *the_objfile : pspace->objfiles ()) { + /* Skip separate debug objects. */ + if (the_objfile->separate_debug_objfile_backlink != nullptr) + continue; + if (the_objfile->skip_jit_symbol_lookup) continue; @@ -833,7 +837,7 @@ jit_breakpoint_re_set_internal (struct gdbarch *gdbarch, program_space *pspace) } jiter_objfile_data *objf_data - = get_jiter_objfile_data (reg_symbol.objfile); + = get_jiter_objfile_data (the_objfile); objf_data->register_code = reg_symbol.minsym; objf_data->descriptor = desc_symbol.minsym;