public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: Keith Seitz <keiths@redhat.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH v2] Really fix gdb/23010: SYMBOL_LANGUAGE != DICT_LANGUAGE assertion
Date: Wed, 11 Jul 2018 01:17:00 -0000	[thread overview]
Message-ID: <33b99113-c705-a029-47df-3e6c0fc49139@simark.ca> (raw)
In-Reply-To: <20180627190341.24442-1-keiths@redhat.com>

Hi Keith,

On 2018-06-27 03:03 PM, Keith Seitz wrote:
> This patch is another attempt at really fixing the multitude of assertions
> being seen where symbols of one language are being added to symbol lists of
> another language.
> 
> In short, this is happening because read_file_scope was reading DIEs without
> having its language set. As a result, the default language,
> language_minimal, was being passed to imported DIE trees and, in certain
> specific situations, causing the SYMBOL_LANGUAGE != DICT_LANGUAGE assertion
> being widely reported.
> 
> For a more thorough explanation, see the following mailing list
> post:
> 
>   https://sourceware.org/ml/gdb-patches/2018-05/msg00703.html

I wouldn't mind if you included the information here.

> Since a test reproducer for this has been so elusive, this patch also adds a
> wrapper function around add_symbol_to_list which asserts when adding a
> symbol of one language to a list containing symbols of a different language.

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.

> Differences from v1:
> - Removed complaint variation
> - Updated comments
> - Fixed typo
> 
> gdb/ChangeLog:
> 
> 	PR gdb/23010
> 	* dwarf2read.c (dw2_add_symbol_to_list): New function.
> 	(fixup_go_packaging, new_symbol): Use dw2_add_symbol_to_list
> 	instead of add_symbol_to_list.
> 	(read_file_scope): Call prepare_one_comp_unit before reading
> 	any other DIEs.
> ---
>  gdb/dwarf2read.c | 29 +++++++++++++++++++++++------
>  1 file changed, 23 insertions(+), 6 deletions(-)
> 
> 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).

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.

Thanks,

Simon

  reply	other threads:[~2018-07-11  1:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-27 19:03 Keith Seitz
2018-07-11  1:17 ` Simon Marchi [this message]
2018-07-12 15:47   ` Keith Seitz
2018-07-12 17:12     ` Simon Marchi
2018-07-24 20:13       ` Simon Marchi
2018-07-24 20:25         ` Keith Seitz
2018-07-12 17:12 ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=33b99113-c705-a029-47df-3e6c0fc49139@simark.ca \
    --to=simark@simark.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=keiths@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).