From: Kevin Buettner <kevinb@redhat.com>
To: gdb-patches@sourceware.org
Cc: Tom Tromey <tromey@adacore.com>
Subject: Re: [PATCH] Fix bug in DW_OP_GNU_variable_value evaluation
Date: Mon, 27 Jul 2020 18:23:20 -0700 [thread overview]
Message-ID: <20200727182320.2aa49b7a@f32-m1.lan> (raw)
In-Reply-To: <20200727204644.2410247-1-tromey@adacore.com>
On Mon, 27 Jul 2020 14:46:44 -0600
Tom Tromey <tromey@adacore.com> wrote:
> A modified version of the gnat compiler (TBH I don't know if the
> modifications are relevant to this bug or not, but I figured I'd
> mention it) can generate a DWARF location expression like:
>
> <1><1201>: Abbrev Number: 3 (DW_TAG_dwarf_procedure)
> <1202> DW_AT_location : 32 byte block: 12 31 29 28 4 0 30 2f 12 0 14 30 2d 28 4 0 14 2f 1 0 30 34 1e 23 3 9 fc 1a 16 13 16 13 (DW_OP_dup; DW_OP_lit1; DW_OP_eq; DW_OP_bra: 4; DW_OP_lit0; DW_OP_skip: 18; DW_OP_over; DW_OP_lit0; DW_OP_lt; DW_OP_bra: 4; DW_OP_over; DW_OP_skip: 1; DW_OP_lit0; DW_OP_lit4; DW_OP_mul; DW_OP_plus_uconst: 3; DW_OP_const1s: -4; DW_OP_and; DW_OP_swap; DW_OP_drop; DW_OP_swap; DW_OP_drop)
>
> <2><1279>: Abbrev Number: 9 (DW_TAG_structure_type)
> <127a> DW_AT_name : (indirect string, offset: 0x1a5a): p__logical_channel_t
> <127e> DW_AT_byte_size : 18 byte block: fd 43 12 0 0 97 94 1 99 34 0 0 0 23 7 9 fc 1a (DW_OP_GNU_variable_value: <0x1243>; DW_OP_push_object_address; DW_OP_deref_size: 1; DW_OP_call4: <0x1201>; DW_OP_plus_uconst: 7; DW_OP_const1s: -4; DW_OP_and)
>
> When evaluated, this gives:
>
> Incompatible types on DWARF stack
>
> In Jakub's original message about DW_OP_GNU_variable_value:
>
> https://gcc.gnu.org/legacy-ml/gcc-patches/2017-02/msg01499.html
>
> .. it says:
>
> The intended behavior is that the debug info consumer computes the
> value of that referenced variable at the current PC, and if it can
> compute it and pushes the value as a generic type integer into the
> DWARF stack
>
> Instead, gdb is using the variable's type -- but this fails with some
> operations, like DW_OP_and, which expect the types to match.
>
> I believe what was intended was for the value to be cast to the DWARF
> "untyped" type, which is what this patch implements. This patch also
> updates varval.exp to exhibit the bug.
>
> gdb/ChangeLog
> 2020-07-27 Tom Tromey <tromey@adacore.com>
>
> * dwarf2/expr.c (dwarf_expr_context::execute_stack_op)
> <DW_OP_GNU_variable_value>: Cast to address type.
>
> gdb/testsuite/ChangeLog
> 2020-07-27 Tom Tromey <tromey@adacore.com>
>
> * gdb.dwarf2/varval.exp (setup_exec): Add 'or' instruction to
> 'varval' location.
LGTM.
Kevin
next prev parent reply other threads:[~2020-07-28 1:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-27 20:46 Tom Tromey
2020-07-28 1:23 ` Kevin Buettner [this message]
2020-07-28 17:01 ` 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=20200727182320.2aa49b7a@f32-m1.lan \
--to=kevinb@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@adacore.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