From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59614 invoked by alias); 12 Jul 2018 15:47:25 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 59603 invoked by uid 89); 12 Jul 2018 15:47:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-24.4 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,KAM_STOCKGEN,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=ha, structured, compose, former 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; Thu, 12 Jul 2018 15:47:23 +0000 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E6AD532B689; Thu, 12 Jul 2018 15:47:21 +0000 (UTC) Received: from theo.uglyboxes.com (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8F4422010CBF; Thu, 12 Jul 2018 15:47:21 +0000 (UTC) Subject: Re: [PATCH v2] Really fix gdb/23010: SYMBOL_LANGUAGE != DICT_LANGUAGE assertion To: Simon Marchi , gdb-patches@sourceware.org References: <20180627190341.24442-1-keiths@redhat.com> <33b99113-c705-a029-47df-3e6c0fc49139@simark.ca> From: Keith Seitz Message-ID: <97d83efa-56b9-0e1a-a6d5-1ee2115c8a99@redhat.com> Date: Thu, 12 Jul 2018 15:47:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <33b99113-c705-a029-47df-3e6c0fc49139@simark.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00339.txt.bz2 On 07/10/2018 06:17 PM, Simon Marchi wrote: > I wouldn't mind if you included the information here. I will certainly include a redux of that analysis in the commit log. > I have a question about the assertion vs complaint. Is it logically > impossible (putting aside other GDB bugs) for this assertion to fail? > Or is it possible now to feed bad debug info to GDB that will trigger > this new assert? If it's the former, then no problem, if it's the later > then an assertion is not appropriate. IMO the former. The code is currently structured so that a dictionary can *only* have symbols of one language inside it. While it may be possible to trigger this with malicious DWARF hacking, I cannot really say for certain that it isn't possible in valid DWARF. [Sorry, that's more of a politician's answer to your question.] >> diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c >> index 4ad0527406..ba70315957 100644 >> --- a/gdb/dwarf2read.c >> +++ b/gdb/dwarf2read.c >> @@ -9701,6 +9701,24 @@ compute_delayed_physnames (struct dwarf2_cu *cu) >> cu->method_list.clear (); >> } >> >> +/* A wrapper for add_symbol_to_list to ensure that SYMBOL's language is >> + the same as all other symbols in LISTHEAD. If a new symbol is added >> + with a different language, this function asserts. */ >> + >> +static inline void >> +dw2_add_symbol_to_list (struct symbol *symbol, struct pending **listhead) >> +{ >> + /* Only assert if LISTHEAD already contains symbols of a different >> + language (dict_create_hashed/insert_symbol_hashed requires that all >> + symbols in this list are of the same language). */ >> + gdb_assert ((*listhead) == NULL >> + || (*listhead)->nsyms == 0 >> + || (SYMBOL_LANGUAGE ((*listhead)->symbol[0]) >> + == SYMBOL_LANGUAGE (symbol))); > > I wonder if it's actually possible to have (*listhead)->nsyms == 0, since as > soon as a "struct pending" is allocated, there is at least one sym put into > it (in add_symbol_to_list). Ha! Yes, that's true. I didn't even look. I just erred on the defensive side. I'll remove that. > It's probably a bit hard to tell for older debug formats, but is it only for > DWARF that this condition must hold? Did you consider putting this assertion > directly in add_symbol_to_list? I'm not saying it's the right thing to do, I'm > just asking. The assertion holds for any debug reader that uses hashed dictionaries, and that list isn't a straightforward list to compose. That's probably why I originally isolated to dwarf2read.c. Or I just plain didn't think about (interfering with) other debuginfo readers. Any symbol reader using add_symbol_to_list could create hashed dictionaries, but AFAICT there is no requirement that it does. Out of curiosity, I moved (and adjusted) the assertion to add_symbol_to_list and ran some tests. As expected, DWARF tests showed no difference. STABS testing, though, triggers the assertion. add_symbol_to_list is often called before any dictionary is created. Thank you for taking a look, Keith