From: Simon Marchi <simark@simark.ca>
To: Pedro Alves <pedro@palves.net>,
Lancelot SIX <Lancelot.Six@amd.com>,
gdb-patches@sourceware.org
Cc: lsix@lancelotsix.com
Subject: Re: [PATCH] gdb/amd-dbgapi-target: Use inf param in detach
Date: Fri, 14 Jul 2023 22:00:23 -0400 [thread overview]
Message-ID: <a799bf56-24e2-5ebf-16ac-64ec1ba03c15@simark.ca> (raw)
In-Reply-To: <31b6963a-6b3a-f18e-9863-40acff23c546@palves.net>
On 7/14/23 15:18, Pedro Alves wrote:
> On 2023-07-14 19:54, Lancelot SIX wrote:
>> On 14/07/2023 19:35, Pedro Alves wrote:
>
>>> IMO this is a case of the target method's inferior * parameter having
>>> been added too soon -- it would only make sense to have it if nothing in
>>> the body of the target method implementations is relying on inf being
>>> current_inferior on entry. But that is not the case, plenty of target_ops::detach
>>> code has that assumption. The presence of an explicit inferior pointer should mean
>>> that detach target method implementations that call code that depends
>>> on the inferior being the current inferior, should be using a
>>> scoped_restore_current_thread/inferior before calling such global-state-assuming
>>> code. But, they don't do that, instead, we have this mixed situation. IMO, it would
>>> be better to remove the parameter to avoid confusion and stick to the
>>> (if explicit param, then switch global state to it if you need it) rule.
I agree with this assessment. I was probably the one adding this
parameter, before I understood that having a function receive the
context by parameter _and_ depend on the global context is bad (worse
than just depending on global context).
>>> Anyhow, your patch doesn't make it worse, so it's fine with me.
>>>
>>
>> I can also go the other way around and always use `current_inferior ()` instead of the `inf` parameter in this detach implementation.
>>
>> What bugged me here is the inconsistency from one line to the next.
>>
>
> Please go ahead and merge your patch. I quickly looked at what it would like to remove
> the parameter throughout, and I think we'd just end up doing:
>
> inferior *inf = current_inferior ();
>
> at the top of the function, so using "inf" in the remove_breakpoints_inf call anyhow, as
> we have multiple references to the current inferior.
Either fix is fine with me.
Simon
next prev parent reply other threads:[~2023-07-15 2:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-16 9:25 Lancelot SIX
2023-07-14 18:35 ` Pedro Alves
2023-07-14 18:54 ` Lancelot SIX
2023-07-14 19:18 ` Pedro Alves
2023-07-15 2:00 ` Simon Marchi [this message]
2023-07-19 8:56 ` Lancelot SIX
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=a799bf56-24e2-5ebf-16ac-64ec1ba03c15@simark.ca \
--to=simark@simark.ca \
--cc=Lancelot.Six@amd.com \
--cc=gdb-patches@sourceware.org \
--cc=lsix@lancelotsix.com \
--cc=pedro@palves.net \
/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).