From: Simon Marchi <simark@simark.ca>
To: Andrew Burgess <aburgess@redhat.com>,
Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>
Cc: Simon Marchi <simon.marchi@efficios.com>
Subject: Re: [PATCH] gdb: error out if architecture does not implement any "return_value" hook
Date: Tue, 28 Feb 2023 14:53:04 -0500 [thread overview]
Message-ID: <b3e447fe-7e36-f254-129a-e5ea20aad8c3@simark.ca> (raw)
In-Reply-To: <87fsapj13v.fsf@redhat.com>
>> diff --git a/gdb/gdbarch_components.py b/gdb/gdbarch_components.py
>> index caa65c334eca..7ceecbf5d223 100644
>> --- a/gdb/gdbarch_components.py
>> +++ b/gdb/gdbarch_components.py
>> @@ -902,11 +902,11 @@ for instance).
>> ("struct value **", "read_value"),
>> ("const gdb_byte *", "writebuf"),
>> ],
>> - predefault="default_gdbarch_return_value",
>> # If we're using the default, then the other method must be set;
>> # but if we aren't using the default here then the other method
>> # must not be set.
>
> I don't think this comment aligns with the postdefault code. It says
> "If we're using the default, ..." but "we" here is
> 'return_value_as_value', but we're actually checking 'return_value'.
Oops, I should have removed it probably.
>> - invalid="(gdbarch->return_value_as_value == default_gdbarch_return_value) == (gdbarch->return_value == nullptr)",
>> + postdefault="gdbarch->return_value != nullptr ? default_gdbarch_return_value : nullptr",
>
> If you search for the postdefault string you'll notice this code is not
> actually generated anywhere! This is a consequence of also having
> defined a predicate.
Wow, that's bad! I really thought it was generated, maybe it was when
trying some other combination of attributes.
> As I say above, the gdbarch.py algorithm could do with some updating in
> a few cases.
>
> The good news is, I already have a patch that fixes this problem. I was
> going to include a link to it here, but turns out I never actually
> posted it! I'm going to try to get that post on the list today, I've
> tried it locally, and with my patch your postdefault code is generated
> correctly.
Thanks a lot. I agree with pretty much all you said above. I think a
GDB port could live without a "return value" hook, but again there might
be no point for us to support that extra complexity. I'll go look at
your series.
Simon
Simon
next prev parent reply other threads:[~2023-02-28 19:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-27 21:28 Simon Marchi
2023-02-28 14:50 ` Andrew Burgess
2023-02-28 16:53 ` Andrew Burgess
2023-02-28 19:53 ` Simon Marchi [this message]
2023-02-28 20:20 ` Pedro Alves
2023-03-01 3:14 ` 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=b3e447fe-7e36-f254-129a-e5ea20aad8c3@simark.ca \
--to=simark@simark.ca \
--cc=aburgess@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=simon.marchi@efficios.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).