public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: "Willgerodt, Felix" <felix.willgerodt@intel.com>
To: "Metzger, Markus T" <markus.t.metzger@intel.com>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	"simark@simark.ca" <simark@simark.ca>
Subject: RE: [PATCH v10 08/10] btrace, linux: Enable ptwrite packets.
Date: Mon, 7 Aug 2023 09:10:50 +0000	[thread overview]
Message-ID: <MN2PR11MB45669C19EBDCE389A9D9EE318E0CA@MN2PR11MB4566.namprd11.prod.outlook.com> (raw)
In-Reply-To: <DM8PR11MB57499FB92B230043DD885E3CDE03A@DM8PR11MB5749.namprd11.prod.outlook.com>

> -----Original Message-----
> From: Metzger, Markus T <markus.t.metzger@intel.com>
> Sent: Dienstag, 25. Juli 2023 15:30
> To: Willgerodt, Felix <felix.willgerodt@intel.com>; gdb-patches@sourceware.org;
> simark@simark.ca
> Subject: RE: [PATCH v10 08/10] btrace, linux: Enable ptwrite packets.
> 
> Hello Felix,
> 
> >+/* Read config bits.  */
> >+
> >+static bool
> >+linux_read_pt_config_bit (const std::string &feature, uint64_t *config_bit)
> 
> This isn't really necessary since the bit resembles the enable bit in the control
> MSR.
> It also doesn't hurt so I'm OK with the change.

I was thinking to re-use this function for future features, like event tracing.
I didn't really dig into Linux code, I just felt that if there is a file for it lets read it.

> >+{
> >+  std::string filename
> >+      = "/sys/bus/event_source/devices/intel_pt/format/" + feature;
> >+  gdb_file_up file = gdb_fopen_cloexec (filename.c_str (), "r");
> >+
> >+  if (file.get () == nullptr || config_bit == nullptr)
> >+    return false;
> 
> We could check CONFIG_BIT before opening the file.

Will do.

> >+
> >+  int found = fscanf (file.get (), "config:%lu", config_bit);
> 
> The format string doesn't match the type.  We should use SCNu64.

Will do.

> >+  if (found != 1)
> >+    {
> >+      warning (_("Failed to determine config bit from %s."),
> >+	       filename.c_str ());
> 
> The issue is that the file didn't contain the expected content.
> This will probably need some changes in GDB to fix.  Could we
> print the actual content and what we expected?

Yes, this could mean that the format changed. But it could also
just be a corrupcted files/system.
I don't think we want to dump the content of a possibly corrupt file.


> >+/* Check whether the linux target supports Intel Processor Trace PTWRITE.  */
> >+
> >+static bool
> >+linux_supports_ptwrite (uint64_t *config_bit)
> >+{
> >+  static const char filename[]
> >+      = "/sys/bus/event_source/devices/intel_pt/caps/ptwrite";
> >+  gdb_file_up file = gdb_fopen_cloexec (filename, "r");
> >+
> >+  if (file.get () == nullptr)
> >+    return false;
> >+
> >+  int status, found = fscanf (file.get (), "%d", &status);
> >+
> >+  if (found != 1)
> >+    {
> >+      warning (_("Failed to determine ptwrite support from %s."), filename);
> >+      return false;
> >+    }
> >+
> >+  if (!linux_read_pt_config_bit ("ptw", config_bit))
> 
> We should check STATUS before.  If caps indicates that ptwrite isn't
> available, I'm not sure format will contain the bit position for enabling
> it.

Makes sense, I will do that.

> >+  uint64_t config_bit;
> >+  if (conf->ptwrite && linux_supports_ptwrite (&config_bit))
> >+    {
> >+      pt->attr.config |= 1 << config_bit;
> >+      tinfo->conf.pt.ptwrite = conf->ptwrite;
> >+    }
> >+
> >   errno = 0;
> >   scoped_fd fd (syscall (SYS_perf_event_open, &pt->attr, pid, -1, -1, 0));
> >   if (fd.get () < 0)
> >diff --git a/gdb/record-btrace.c b/gdb/record-btrace.c
> >index c93b3d7c8de..ad3160d42c5 100644
> >--- a/gdb/record-btrace.c
> >+++ b/gdb/record-btrace.c
> >@@ -3295,4 +3295,9 @@ to see the actual buffer size."), NULL,
> >show_record_pt_buffer_size_value,
> >
> >   record_btrace_conf.bts.size = 64 * 1024;
> >   record_btrace_conf.pt.size = 16 * 1024;
> >+#if (LIBIPT_VERSION >= 0x200)
> >+  record_btrace_conf.pt.ptwrite = true;
> >+#else
> >+  record_btrace_conf.pt.ptwrite = false;
> >+#endif
> 
> Is there a way to get an error when attempting to install a custom
> ptwrite filter when either GDB (via libipt) or the kernel does not
> support PTWRITE?

Good point. Unfortunately I don't see one with the current design.
Currently we just cache the filter functions in python when one is
registered. The configuration isn't exposed to the python layer in
any way.

I am not sure how we could do this. Exposing "maint btrace info"
and parsing that would be one way, not sure if we want to go down
that path.

Thanks,
Felix
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

  reply	other threads:[~2023-08-07  9:11 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-18 11:56 [PATCH v10 00/10] Extensions for PTWRITE Felix Willgerodt
2023-07-18 11:56 ` [PATCH v10 01/10] btrace: Introduce auxiliary instructions Felix Willgerodt
2023-07-18 11:56 ` [PATCH v10 02/10] btrace: Enable auxiliary instructions in record instruction-history Felix Willgerodt
2023-07-18 11:56 ` [PATCH v10 03/10] btrace: Enable auxiliary instructions in record function-call-history Felix Willgerodt
2023-07-18 11:56 ` [PATCH v10 04/10] btrace: Handle stepping and goto for auxiliary instructions Felix Willgerodt
2023-07-18 11:56 ` [PATCH v10 05/10] python: Introduce gdb.RecordAuxiliary class Felix Willgerodt
2023-07-25 13:30   ` Metzger, Markus T
2023-08-07  9:08     ` Willgerodt, Felix
2023-08-08  9:37       ` Metzger, Markus T
2023-08-09  9:32         ` Willgerodt, Felix
2023-08-09 10:00           ` Metzger, Markus T
2023-08-30  8:39             ` Willgerodt, Felix
2023-07-18 11:56 ` [PATCH v10 06/10] python: Add clear() to gdb.Record Felix Willgerodt
2023-07-18 13:00   ` Eli Zaretskii
2023-07-18 11:56 ` [PATCH v10 07/10] btrace, gdbserver: Add ptwrite to btrace_config_pt Felix Willgerodt
2023-07-18 11:56 ` [PATCH v10 08/10] btrace, linux: Enable ptwrite packets Felix Willgerodt
2023-07-25 13:30   ` Metzger, Markus T
2023-08-07  9:10     ` Willgerodt, Felix [this message]
2023-08-08 10:13       ` Metzger, Markus T
2023-08-09  9:31         ` Willgerodt, Felix
2023-08-09  9:48           ` Metzger, Markus T
2023-08-30  8:42             ` Willgerodt, Felix
2023-09-06 14:07               ` Metzger, Markus T
2023-07-18 11:56 ` [PATCH v10 09/10] btrace, python: Enable ptwrite filter registration Felix Willgerodt
2023-07-18 11:56 ` [PATCH v10 10/10] btrace: Extend ptwrite event decoding Felix Willgerodt
2023-07-18 13:01   ` Eli Zaretskii

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=MN2PR11MB45669C19EBDCE389A9D9EE318E0CA@MN2PR11MB4566.namprd11.prod.outlook.com \
    --to=felix.willgerodt@intel.com \
    --cc=gdb-patches@sourceware.org \
    --cc=markus.t.metzger@intel.com \
    --cc=simark@simark.ca \
    /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).