From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 32E54383F854 for ; Wed, 27 May 2020 20:03:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 32E54383F854 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [172.16.0.95] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (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 C61D01E5F9; Wed, 27 May 2020 16:03:06 -0400 (EDT) Subject: Re: [PATCH v2 28/42] Remove dwarf2_per_cu_data::objfile () To: Tom de Vries , Simon Marchi , gdb-patches@sourceware.org References: <20200512210913.5593-1-simon.marchi@efficios.com> <20200512211250.6230-29-simon.marchi@efficios.com> <04473d43-9719-436b-648a-bdc8e5f55751@suse.de> From: Simon Marchi Message-ID: Date: Wed, 27 May 2020 16:03:05 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <04473d43-9719-436b-648a-bdc8e5f55751@suse.de> Content-Type: text/plain; charset=utf-8 Content-Language: tl Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Wed, 27 May 2020 20:03:09 -0000 On 2020-05-27 12:27 p.m., Tom de Vries wrote: > On 12-05-2020 23:12, Simon Marchi via Gdb-patches wrote: >> @@ -724,10 +721,13 @@ class dwarf_evaluate_loc_desc : public dwarf_expr_context >> caller_frame = get_prev_frame (frame); >> >> parameter = dwarf_expr_reg_to_entry_parameter (frame, kind, kind_u, >> - &caller_per_cu); >> + &caller_per_cu, >> + &caller_per_objfile); >> data_src = deref_size == -1 ? parameter->value : parameter->data_value; >> size = deref_size == -1 ? parameter->value_size : parameter->data_value_size; >> >> + gdb_assert (this->per_objfile == caller_per_objfile); >> + > > Hi, > > I'm running into this assert here: > ... > (gdb) PASS: gdb.base/catch-load.exp: plain load: catch load > continue^M > Continuing.^M > ^M > Catchpoint 3^M > Inferior loaded > /data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/catch-load/catch-load-so.so^M > dl_open_worker (/data/gdb_versions/devel/src/gdb/dwarf2/loc.c:729: > internal-error: virtual void > dwarf_evaluate_loc_desc::push_dwarf_reg_entry_value(call_site_parameter_kind, > call_site_parameter_u, int): Assertion `this->per_objfile == > caller_per_objfile' failed.^M > A problem internal to GDB has been detected,^M > further debugging may prove unreliable.^M > Quit this debugging session? (y or n) FAIL: gdb.base/catch-load.exp: > plain load: continue (GDB internal error) I don't see this failure. Is it with a particular board file? Or maybe gcc-version specific? It looks related to what we have discussed here: https://sourceware.org/pipermail/gdb-patches/2020-May/168906.html I think the fix would be to temporarily override this->per_objfile to be caller_per_objfile (with a scoped_restore). But I'd like to be able to reproduce it to understand what's happening. Simon