public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Zoran Zaric <Zoran.Zaric@amd.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v2] Replace the symbol needs evaluator with a parser
Date: Wed, 21 Oct 2020 14:35:51 -0600	[thread overview]
Message-ID: <87imb3gvvc.fsf@tromey.com> (raw)
In-Reply-To: <20201007172613.21868-1-Zoran.Zaric@amd.com> (Zoran Zaric's message of "Wed, 7 Oct 2020 18:26:13 +0100")

>>>>> "Zoran" == Zoran Zaric <Zoran.Zaric@amd.com> writes:

Zoran> This patch addresses a design problem with the symbol_needs_eval_context
Zoran> class. It exposes the problem by introducing two new testsuite test
Zoran> cases.

Thank you for the patch.

Zoran> This is clearly a wrong result and it causes the debugger to crash.

One question I have here is whether we even need this symbol-needs-frame
stuff.  What if, instead, we just had gdb throw an exception in the
situation where a frame is needed but not available?  Then we could get
rid of the asserts and gdb would simply print an error rather than
crash.

Can you look to see if that is feasible?  The main advantage I see here
is that this approach would avoid the problem we sometimes have of
updating one DWARF expression-decoder and then forgetting to update the
others...

Zoran> A more desired long term design would be to have one class that deals
Zoran> with parsing of the DWARF expression, while there would be a virtual
Zoran> methods that deal with specifics of some DWARF operations. Then that
Zoran> class would be used as a base for all DWARF expression parsing mentioned
Zoran> at the beginning.

What I did in gimli is have a parser that converts the DWARF expression
to an internal form.  Then users of the API can decide how to manipulate
this form -- dump it, evaluate it, etc.  This separates the low-level
parsing bits from the decisions about what operations to perform.

Zoran> gdb/ChangeLog:

Zoran>         * dwarf2/loc.c (class symbol_needs_eval_context): Remove.

This is PR gdb/10592 and so that should be mentioned in both ChangeLogs.

thanks,
Tom

  reply	other threads:[~2020-10-21 20:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-07 17:26 Zoran Zaric
2020-10-21 20:35 ` Tom Tromey [this message]
2020-10-22 14:58   ` Zaric, Zoran (Zare)
2020-10-27 19:51     ` Pedro Alves
2020-11-12 20:03     ` Tom Tromey
2020-11-12 20:11 ` Tom Tromey
2020-11-12 21:17   ` Zaric, Zoran (Zare)
2020-11-12 21:29     ` Zaric, Zoran (Zare)
2020-11-30 18:18       ` Zaric, Zoran (Zare)

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=87imb3gvvc.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=Zoran.Zaric@amd.com \
    --cc=gdb-patches@sourceware.org \
    /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).