From: Tom Tromey <tom@tromey.com>
To: Jielun Wu <firmiana402@gmail.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb: Reject non-base type operands in typed DWARF expressions
Date: Fri, 23 Oct 2026 12:32:40 -0600 [thread overview]
Message-ID: <87h5icqncn.fsf@tromey.com> (raw)
In-Reply-To: <20260805075933.3130855-1-firmiana402@gmail.com> (Jielun Wu's message of "Wed, 5 Aug 2026 15:59:33 +0800")
>>>>> Jielun Wu <firmiana402@gmail.com> writes:
> DWARF typed expression operators require a type operand that names a
> DW_TAG_base_type DIE. This applies to DW_OP_const_type,
> DW_OP_regval_type, DW_OP_deref_type, and the nonzero type operands of
> DW_OP_convert and DW_OP_reinterpret.
Thanks.
> dwarf_expr_context::get_base_type documents that contract, but its
> implementation accepted any DIE that resolved to a GDB type. As a
> result, typed expression operators could accept non-base DIEs such as
> DW_TAG_structure_type.
> Add dwarf2_get_base_type to resolve the referenced DIE, reject invalid or
> non-base DIEs, and return the corresponding base type. Use it from the
> DWARF expression evaluator.
> Add a DWARF assembler test covering DW_OP_const_type with a
> DW_TAG_structure_type type operand.
I wonder whether this is truly worth checking; or at least whether it is
worth checking in this way.
> +/* See read.h. */
> +
> +struct type *
> +dwarf2_get_base_type (cu_offset die_offset, dwarf2_per_cu *per_cu,
> + dwarf2_per_objfile *per_objfile)
> +{
> + dwarf2_cu *cu = per_objfile->get_cu (per_cu);
> + if (cu == nullptr)
> + cu = load_cu (per_cu, per_objfile, false);
This re-reads all the DIEs, which may be expensive. But the only reason
this would be needed is to check a DWARF constraint.
It doesn't really matter, I think, if gdb accepts a "reasonable"
expression that isn't technically correct according to DWARF. gdb does
similar things in many places already, there are a bunch of supported
DWARF extensions.
Now, at the same time, we may not want to allow any old type to be
returned. But this could be done by looking for "base-like" types --
basically scalars of various kinds -- and rejecting others.
Full checking of this kind of thing could be done in a dwarflint tool,
should that ever end up being real.
> + _op .byte $_constants(DW_OP_const_type)
> + _op .uleb128 "$struct_label - $_cu_label"
> + _op .byte 4
> + _op .byte 1
> + _op .byte 2
> + _op .byte 3
> + _op .byte 4
See that other patch, a handler should be written for this.
Tom
prev parent reply other threads:[~2026-10-23 18:33 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 7:59 Jielun Wu
2026-10-23 18:32 ` Tom Tromey [this message]
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=87h5icqncn.fsf@tromey.com \
--to=tom@tromey.com \
--cc=firmiana402@gmail.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