From: "Metzger, Markus T" <markus.t.metzger@intel.com>
To: Yao Qi <qiyaoltc@gmail.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: RE: [PATCH] btrace, gdbserver: check btrace target pointers
Date: Wed, 28 Feb 2018 17:11:00 -0000 [thread overview]
Message-ID: <A78C989F6D9628469189715575E55B236964E20C@IRSMSX104.ger.corp.intel.com> (raw)
In-Reply-To: <86sh9lgjxt.fsf@gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1953 bytes --]
Hello Yao,
Thanks for your review.
> > -#define target_enable_btrace(ptid, conf) \
> > - (*the_target->enable_btrace) (ptid, conf)
> > +static inline struct btrace_target_info *
> > +target_enable_btrace (ptid_t ptid, const struct btrace_config *conf)
> > +{
> > + if (the_target->enable_btrace == nullptr)
> > + error ("Target does not support branch tracing.");
> > +
> > + return (*the_target->enable_btrace) (ptid, conf);
> > +}
>
> It is reasonable to me that (*the_target->enable_btrace) may throw
> various exceptions due to different reasons, but I am not convinced that
> we should error on (the_target->enable_btrace == nullptr). I don't like
> replacing control flow logic with exception. This is my personal
> flavor. Instead, can we check
> (the_target->enable_btrace == nullptr) before using
> target_enable_btrace, and error in handle_btrace_general_set if
> thread->btrace is NULL. What do you think?
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?
Regards,
Markus.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
\x16º&Öéj×!zÊÞ¶êç×zïIb²Ö«r\x18\x1dnr\x17¬
next prev parent reply other threads:[~2018-02-28 17:11 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 [this message]
2018-03-01 9:15 ` Yao Qi
2018-03-01 11:09 ` Pedro Alves
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=A78C989F6D9628469189715575E55B236964E20C@IRSMSX104.ger.corp.intel.com \
--to=markus.t.metzger@intel.com \
--cc=gdb-patches@sourceware.org \
--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