From: Pedro Alves <palves@redhat.com>
To: Simon Marchi <simon.marchi@ericsson.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Make dwarf_expr_context::stack an std::vector
Date: Thu, 14 Sep 2017 16:13:00 -0000 [thread overview]
Message-ID: <4470557a-be38-3188-9076-2b70cc253b7a@redhat.com> (raw)
In-Reply-To: <1505404760-11844-1-git-send-email-simon.marchi@ericsson.com>
On 09/14/2017 04:59 PM, Simon Marchi wrote:
> Replace the manually managed array with a vector. It is mostly
> straightforward, except maybe one thing in execute_stack_op, in the
> handling of DW_OP_fbreg. When the code stumbles on that opcode while
> evaluating an expression, it needs to evaluate a subexpression to find
> where the fb reg has been saved. Rather than creating a new context, it
> reuses the current context. It saves the size of the stack before and
> restores the stack to that size after.
>
> I think we can do a little bit better by saving the current stack
> locally and installing a new empty stack. This way, if the
> subexpression is malformed and underflows, we'll get an exception.
> Before, it would have overwitten the top elements of the top-level
"overwritten"
> expression. The evaluation of the top-level expression would have then
> resumed with the same stack size, but possibly some corrupted elements.
One difference this causes is that before we're reuse the
vector's internal memory buffer for the recursion, which may have
been reallocated sufficiently already and not require any further reallocation,
while with the patch, we must always heap-allocate the new vector's
internal buffer when recursion pushes a value, and release it when recursion
unwinds. I assume that it doesn't cause an observable timing
difference, but, mentioning for completeness.
A couple nits and this is fine with me.
> /* True if the piece is in memory and is known to be on the program's stack.
> @@ -114,7 +118,7 @@ struct dwarf_stack_value
> struct dwarf_expr_context
> {
> dwarf_expr_context ();
> - virtual ~dwarf_expr_context ();
> + virtual ~dwarf_expr_context () = default;
Couldn't we just remove the dtor?
>
> void push_address (CORE_ADDR value, bool in_stack_memory);
> void eval (const gdb_byte *addr, size_t len);
> @@ -123,11 +127,7 @@ struct dwarf_expr_context
> bool fetch_in_stack_memory (int n);
>
> /* The stack of values, allocated with xmalloc. */
"xmalloc" reference is stale.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2017-09-14 16:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-14 15:59 Simon Marchi
2017-09-14 16:13 ` Pedro Alves [this message]
2017-09-14 16:31 ` Simon Marchi
2017-09-14 16:43 ` Pedro Alves
2017-09-14 20:39 ` Simon Marchi
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=4470557a-be38-3188-9076-2b70cc253b7a@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=simon.marchi@ericsson.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