From: Pedro Alves <palves@redhat.com>
To: Yao Qi <qiyaoltc@gmail.com>,
"Metzger, Markus T" <markus.t.metzger@intel.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH] btrace, gdbserver: check btrace target pointers
Date: Thu, 01 Mar 2018 11:09:00 -0000 [thread overview]
Message-ID: <c2c1493b-7510-9ace-9a83-1a475e7449a7@redhat.com> (raw)
In-Reply-To: <CAH=s-PM_Ctt1ms-4C41uinJ+LOb7=b4YJWPBsQ5M3wG4SZuTDQ@mail.gmail.com>
On 03/01/2018 09:14 AM, Yao Qi wrote:
> On Wed, Feb 28, 2018 at 5:10 PM, Metzger, Markus T
> <markus.t.metzger@intel.com> wrote:
>>
>> I moved two of those checks into the target_* method since I thought
>> it would be a good idea to be able to handle exceptions and since I had
>> to add the TRY/CATCH/CATCH_END, anyway, I thought it made sense
>> to handle the nullptr case also via exceptions.
>>
>> If we're not doing it that way, the caller would need to check the pointer
>> (either directly or via a *_p () function like we do with gdbarch) and still
>> be prepared to handle exceptions from the actual call.
>>
>> My motivation was to simplify the caller but if you think the other way
>> is clearer I can move the check back into the callers. Is that your preference?
>>
>
> I don't have a strong opinion on this. It is more about personal flavour of
> writing code. You are the major btrace contributor, so it is better to keep
> the code in a way you prefer. Patch is good to me, please push.
To me too.
A comment based on my experience hacking on the multi-target branch:
I like imagining how the code would look like if it were C++-ified already.
Here, if gdbserver's target_ops function pointers are converted to C++ methods,
then it'll no longer be possible to check for null pointer. [1]
So, whatever we do, I think checking for null pointers in function
pointer tables is the option that just kicks the can down the road.
The only options here then will be error out or check a *_p() function upfront.
The latter is another way to say, go back to having a supports_btrace method,
I guess.
[*] - I've run into some cases like these in my gdb target_ops C++-ification
in my multi-target branch. Like e.g., I had to add
target_ops::can_create_inferior to replace target_ops->to_create_inferior
null pointer checks.
Thanks,
Pedro Alves
prev parent reply other threads:[~2018-03-01 11:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-27 10:39 Markus Metzger
2018-02-28 16:26 ` Yao Qi
2018-02-28 17:11 ` Metzger, Markus T
2018-03-01 9:15 ` Yao Qi
2018-03-01 11:09 ` Pedro Alves [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=c2c1493b-7510-9ace-9a83-1a475e7449a7@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=markus.t.metzger@intel.com \
--cc=qiyaoltc@gmail.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