public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: 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 20:18:24 +0100	[thread overview]
Message-ID: <31b6963a-6b3a-f18e-9863-40acff23c546@palves.net> (raw)
In-Reply-To: <05217693-1a01-bffb-e74a-503b3fe3a604@amd.com>

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.
>>
>> 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.

Pedro Alves


  reply	other threads:[~2023-07-14 19:18 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 [this message]
2023-07-15  2:00       ` Simon Marchi
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=31b6963a-6b3a-f18e-9863-40acff23c546@palves.net \
    --to=pedro@palves.net \
    --cc=Lancelot.Six@amd.com \
    --cc=gdb-patches@sourceware.org \
    --cc=lsix@lancelotsix.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).