public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Keith Seitz <keiths@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC PATCH] Introduce dwarf2_cu::get_builder
Date: Fri, 16 Nov 2018 13:19:00 -0000	[thread overview]
Message-ID: <077020e3a67e027bf358b899ba9ebdd4@polymtl.ca> (raw)
In-Reply-To: <20181023185715.23082-1-keiths@redhat.com>

On 2018-10-23 14:57, Keith Seitz wrote:
> This patch is an attempt to deal with a variety of bugs reported where
> GDB segfaults attempting to access a dwarf2_cu's builder.  In certain
> circumstances, this builder can be NULL.
> 
> The approach taken here is to save the ancestor CU into the dwarf2_cu 
> of
> all CUs with DIEs that are "imported."  This can happen whenever
> follow_die_offset and friends are called.  This essentially introduces 
> a
> chain of CUs that caused the importation of a DIE from a CU.  Whenever
> a builder is requested of a CU that has none, the ancestors are 
> searched
> for the first one with a builder.
> 
> The bulk of the patch is relatively mindless text conversion from
> "cu->builder" to "cu->get_builder ()".  I've included one test which
> was derived from one (of the many) bugs reported on the issue in both
> sourceware and Fedora bugzillas.
> 
> I'm submitting this as an RFC rather than an actual patch because of 
> the
> lack of coverage testing for all the places where get_builder() is 
> used.

Hi Keith,

I can't give meaningful comments yet, because this deals with cases I'm 
not really used to.

With the way you did it, I'm confident that the behavior will not change 
for existing cases, since we will end up using the same builder as 
before.  Only in those cases where it would have been NULL (and thus 
would have caused a segfault) will the behavior change.  And if it gives 
some good results for these cases, then it seems right.

I noticed there were still some "naked" access to builder (places that 
don't use get_builder).  fixup_go_packaging is one, for example.  Is it 
expected or should they be converted too?

Simon

  parent reply	other threads:[~2018-11-16 13:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-23 18:57 Keith Seitz
2018-10-23 19:41 ` Sergio Durigan Junior
2018-11-06 21:34 ` Keith Seitz
2018-11-14 16:20   ` Keith Seitz
2018-11-16 13:19 ` Simon Marchi [this message]
2018-11-16 14:39   ` Keith Seitz
2018-11-30 20:30 ` Tom Tromey
2019-01-08 19:56   ` Keith Seitz
2019-01-16 16:38     ` Tom Tromey
2019-01-16 19:44       ` Keith Seitz

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=077020e3a67e027bf358b899ba9ebdd4@polymtl.ca \
    --to=simon.marchi@polymtl.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).