From: Tom de Vries <tdevries@suse.de>
To: Tom Tromey <tom@tromey.com>
Cc: Gary Benson via Gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] KFAIL variable-length array tests which fail with Clang
Date: Fri, 20 Nov 2020 17:30:02 +0100 [thread overview]
Message-ID: <55e92b95-8b3b-6c4f-a572-9d7f836a1758@suse.de> (raw)
In-Reply-To: <87y2iwgh90.fsf@tromey.com>
On 11/20/20 4:50 PM, Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
>
> Tom> + gdb_byte last = block->data[block->size - 1];
> Tom> + baton->locexpr.is_reference
> Tom> + = !(last == DW_OP_stack_value || last == DW_OP_implicit_value);
>
> I don't really understand the is_reference stuff
In case a dwarf expression is used for an DW_AT_location attribute, by
default it represents an address, and needs to be dereferenced to get
the value.
> but my first reaction
> is that it must be incorrect somehow.
>
> Anyway, gdb can't do this sort of check. It will fail if the expression
> has a different shape, which is completely allowed by the spec.
So, I'm referring to this bit in the dwarf standard (v4):
...
2.6.1.1.3 Implicit Location Descriptions
An implicit location description represents a piece or all of an object
which has no actual location but whose contents are nonetheless either
known or known to be undefined.
The following DWARF operations may be used to specify a value that has
no location in the program but is a known constant or is computed from
other locations and values in the program.
...
2.DW_OP_stack_value
The DW_OP_stack_value operation specifies that the object does not exist
in memory but its value is nonetheless known and is at the top of the
DWARF expression stack. In this form of location description, the DWARF
expression represents the actual value of the object, rather than its
location. The DW_OP_stack_value operation terminates the expression.
...
AFAIU, the spec specifically says how to interpret a DW_OP_stack_value
at the end of the dwarf expression which is used a location description,
and the code in the patch follows that reasoning.
So, for my understanding, can you give an example of the problem you're
envisioning?
Thanks,
- Tom
next prev parent reply other threads:[~2020-11-20 16:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-16 17:17 Gary Benson via Gdb-patches
2020-11-18 16:14 ` Tom Tromey
2020-11-19 22:53 ` Tom de Vries
2020-11-20 15:15 ` [PATCH][gdb/symtab] Fix gdb.base/vla-optimized-out.exp with clang Tom de Vries
2020-11-21 17:16 ` [gdb/testsuite] Add clang xfail in gdb.base/vla-ptr.exp Tom de Vries
2020-11-20 15:50 ` [PATCH] KFAIL variable-length array tests which fail with Clang Tom Tromey
2020-11-20 16:30 ` Tom de Vries [this message]
2020-11-20 16:51 ` Tom Tromey
2020-11-23 10:34 ` [PATCH][gdb/symtab] Fix gdb.base/vla-optimized-out.exp with clang Tom de Vries
2020-11-25 14:50 ` Gary Benson via Gdb-patches
2020-11-25 15:25 ` Gary Benson via Gdb-patches
2020-11-25 20:05 ` Tom de Vries
2020-11-26 10:10 ` Gary Benson via Gdb-patches
2020-11-30 12:51 ` [committed][PATCH][gdb/symtab] " Tom de Vries
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=55e92b95-8b3b-6c4f-a572-9d7f836a1758@suse.de \
--to=tdevries@suse.de \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.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