From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id qvvdIqu+p2CUfAAAWB0awg (envelope-from ) for ; Fri, 21 May 2021 10:07:39 -0400 Received: by simark.ca (Postfix, from userid 112) id 86E401F11C; Fri, 21 May 2021 10:07:39 -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.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 9876B1E813 for ; Fri, 21 May 2021 10:07:38 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 71E3F384C00B; Fri, 21 May 2021 14:07:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 71E3F384C00B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1621606057; bh=xaQtRPnkGh/kUJlm9v2yS7Lbd5bwheJ+6hrYBL8PTTw=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=gKimYCviWB+/U+LiTxTmv+gLe0ayBZnRM706VV6mFwOA+W12LjAyQxLrr2Nbdtkg6 x6eZ3ZN7/QK6unlxZonfyevzDzLffpgwglJV9FKXjHx0Uy4zUoFVljpgzzjF83Hf2l +ISZ4061MwReWDBxarwq4+3XR/eRFT2B+CN7I5pw= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 5C92B384C00B for ; Fri, 21 May 2021 14:07:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5C92B384C00B Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 14LE7S1I005716 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 May 2021 10:07:33 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 14LE7S1I005716 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 7A2691E813; Fri, 21 May 2021 10:07:28 -0400 (EDT) Subject: Re: [PATCH][gdb/breakpoint] Fix assert in jit_event_handler To: Tom de Vries , gdb-patches@sourceware.org References: <20210520152938.GA31635@delia> Message-ID: <93d1a6e5-583d-a862-e83d-aea2c2be2bd6@polymtl.ca> Date: Fri, 21 May 2021 10:07:17 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Fri, 21 May 2021 14:07:28 +0000 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: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2021-05-21 7:27 a.m., Tom de Vries wrote: > On 5/20/21 6:22 PM, Simon Marchi wrote: >> It's quite annoying that separate debug info files are represented by >> "objfile"s... >> > > Yeah, indeed. > > And you could even say that that's fine, but question whether they > should be in the objfiles list, that is, have the default behaviour of: > ... > for (objfile *the_objfile : pspace->objfiles ()) > { > + /* Skip separate debug objects. */ > + if (the_objfile->separate_debug_objfile_backlink != nullptr) > + continue; > ... > without having to specify this, and if you need to access the separate > debuginfo files, use the specific iterator for this. I think that would be a good idea to explore. In my opinion, the fact that an objfile has separate debug info should be pretty much transparent to the rest of GDB. So I think it would make sense for these special objfiles to be hidden, unless you explicitly ask for them. >>> ... >>> 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. >> >> Does that fix some test when running the testsuite with the fission >> board or something like that? > > No, though I ran into another problem :) while playing around with the > jit test-cases and target boards ( > https://sourceware.org/bugzilla/show_bug.cgi?id=27893 ). Well, good news that you caught it! > [ And yet > another problem while looking into the missing DIE problem ( > https://sourceware.org/bugzilla/show_bug.cgi?id=27894 ). I do stumble on that sometimes. > >> I think it would be important for this to >> be tested. >> > > I wrote this target board file, which does trigger this assert in the > jit test-cases, and verified that the patch fixes all of them. I thought that fission meant "separate debug info", but I think I was wrong... I always confuse fission and separate debug info. We don't already have a board file that generates separate debug info, in that sense: https://sourceware.org/gdb/current/onlinedocs/gdb/Separate-Debug-Files.html ? Looks like we don't, so it would be useful to add one. Since there are two ways of specifying separate debug info (by debuglink and by build-id, I think it would be nice to have a board for each. But just adding the debuglink one would already be an improvement. And once the separate debug info file is found, I guess the code paths don't differ much based on through which method the file was found. > During testing of the target board, I ran into another assert in > gdb.python/py-objfile.exp, will file that as well. WDYT? I think that board file should be added. Simon