public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: "Metzger, Markus T" <markus.t.metzger@intel.com>
To: "Willgerodt, Felix" <felix.willgerodt@intel.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: RE: [PATCH v3 12/12] btrace: Extend ptwrite event decoding.
Date: Fri, 13 Aug 2021 13:36:34 +0000	[thread overview]
Message-ID: <DM8PR11MB57498333B8BB4EBC8C825747DEFA9@DM8PR11MB5749.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20210616074205.1129553-13-felix.willgerodt@intel.com>

Thanks, Felix,

>+	case ptev_ptwrite:
>+	  {
>+	    uint64_t *ip = nullptr;
>+	    gdb::unique_xmalloc_ptr<char> ptw_string = nullptr;
>+	    struct btrace_insn ptw_insn;
>+	    btrace_insn_flags flags;

We're meanwhile declaring variables where they are initialized and used.  The rest of the code has not been updated but new code should follow this.

>+
>+	    /* Lookup the ip if available.  */
>+	    if (event.ip_suppressed == 0)
>+	      ip = &event.variant.ptwrite.ip;
>+	    else if (!btinfo->functions.empty ()
>+		     && !btinfo->functions.back ().insn.empty ())
>+	      ip = &btinfo->functions.back ().insn.back ().pc;

This isn't necessary; libipt will fill in the IP.  It suffices to check for EVENT.IP_SUPPRESSED.

>+
>+	    if (btinfo->ptw_callback_fun != nullptr)

This is probably the first check we should do, i.e. if it is nullptr, break right at the beginning.

>+	      ptw_string = btinfo->ptw_callback_fun (
>+					  &event.variant.ptwrite.payload, ip,
>+					  btinfo->ptw_listener);

The indentation looks a bit odd.  You may break before '= btinfo->...'  if the line is getting too long, otherwise.

>+
>+	    if (ptw_string == nullptr)
>+	      break;
>+
>+	    btinfo->aux_data.emplace_back (ptw_string.get ());
>+
>+	    if (!btinfo->functions.empty ()
>+		&& !btinfo->functions.back ().insn.empty ())
>+	      flags = btinfo->functions.back ().insn.back ().flags;
>+	    else
>+	      flags = 0;
>+
>+	    /* Update insn list with ptw payload insn.  */

We should probably start by memset()ing ptw_insn to all-zero.

>+If an inferior uses the instruction, @value{GDBN} inserts the raw payload value

Maybe add 'by default' to stress that this behavior can be overwritten, which is documented below.

>+load_lib gdb-python.exp
>+
>+if { [skip_btrace_pt_tests] } {
>+    unsupported "Target does not support record btrace pt."
>+    return -1
>+}
>+
>+if { [skip_btrace_ptw_tests] } {
>+    unsupported "Hardware does not support ptwrite instructions."
>+    return -1
>+}
>+
>+# Test libipt version (must be >= 2.0.0).
>+if {[require_libipt_version 2 0 0]} {
>+    unsupported "Libipt doesn't support ptwrite decoding."
>+    return -1
>+}

We shouldn't need to check the patch version.  See comments on a previous patch regarding feature checking.  We can probably combine it with skip_btrace_ptw_tests.

>+### 1. Default testrun
>+
>+# Setup recording
>+gdb_test_no_output "set record instruction-history-size unlimited" "Default: set
>unlimited"
>+gdb_test_no_output "record btrace pt" "Default: record btrace pt"
>+gdb_test "next" ".*" "Default: first next"
>+gdb_test "next" ".*" "Default: second next"

You may use with_test_prefix to add the "Default: " prefix to the test output.  This groups tests and makes it a bit more readable IMHO.  For the above group, the first two wouldn't need any additional test name string.  And if you combined the latter two into "next 2", it wouldn't either.

>+# Test payload printing during stepping
>+gdb_test "record goto 10" "No such instruction\."
>+gdb_test "record goto 9" ".*ptwrite64.* at .*ptwrite.c:23.*"
>+gdb_test "stepi" ".*\\\[42\\\].*"
>+gdb_test "reverse-stepi" ".*\\\[42\\\].*"
>+gdb_test "continue" ".*\\\[42\\\].*\\\[43\\\].*"
>+gdb_test "reverse-continue" ".*\\\[43\\\].*\\\[42\\\].*"

Between [42] and [43] we wouldn't get any other output we need to ignore, would we?  There's multi_line to capture multiple lines of output.

>+# Test auxiliary type in python
>+gdb_test_multiline "auxiliary type in python" \
>+  "python" "" \
>+  "h = gdb.current_recording().instruction_history" "" \
>+  "for insn in h: print(insn)" "" \
>+  "end" [multi_line \
>+  ".*RecordAuxiliary.*" \
>+  ".*RecordAuxiliary.*" \
>+  ]

Could we inspect the auxiliary records to see if we get the correct strings?  Also, it would be nice to print the surrounding instructions instead of ignoring all the output.

If we just printed the instruction_history, wouldn't we get output very similar to the CLI?


>+### 2. Test listener registration
>+### 2.1 Custom listener
>+
>+gdb_test_multiline "Custom: register listener in python" \
>+  "python" "" \
>+  "def my_listener(payload, ip):" "" \
>+  "    if  payload == 66:" "" \
>+  "        return \"payload: {0}, ip: {1:#x}\".format(payload, ip)" "" \
>+  "    else:" "" \
>+  "        return None" "" \
>+  "import gdb.ptwrite" "" \
>+  "gdb.ptwrite.register_listener(my_listener)" "" \
>+  "end" ""
>+
>+gdb_test "record instruction-history 1" [multi_line \
>+  ".*\[0-9\]+\t   $hex <ptwrite64\\+\[0-9\]+>:\tptwrite %\[a-z\]+" \
>+  "\[0-9\]+\t   \\\[payload: 66, ip: $hex\\\]" \
>+  ".*\[0-9\]+\t   $hex <ptwrite32\\+\[0-9\]+>:\tptwrite %\[a-z\]+" \
>+  "\[0-9\]+\t   $hex <ptwrite32\\+\[0-9\]+>:.*" \

What output do we need to ignore here at the beginning of every other line?


>+# Run a test on the target to see if it supports ptwrite instructions.
>+# Return 0 if so, 1 if it does not.  Based on 'check_vmx_hw_available'
>+# from the GCC testsuite.

See above comments.  I think we should simply record a single ptwrite inside main() and check that GDB can decode the trace without errors - and check 'info record' that we actually decoded something.

Regards,
Markus.
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


  parent reply	other threads:[~2021-08-13 13:36 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-16  7:41 [PATCH v3 00/12] Extensions for PTWRITE Felix Willgerodt
2021-06-16  7:41 ` [PATCH v3 01/12] btrace: Introduce auxiliary instructions Felix Willgerodt
2021-08-12 11:06   ` Metzger, Markus T
2022-05-06 11:26     ` Willgerodt, Felix
2021-06-16  7:41 ` [PATCH v3 02/12] btrace: Enable auxiliary instructions in record instruction-history Felix Willgerodt
2021-08-12 11:06   ` Metzger, Markus T
2022-05-06 11:26     ` Willgerodt, Felix
2021-06-16  7:41 ` [PATCH v3 03/12] btrace: Enable auxiliary instructions in record function-call-history Felix Willgerodt
2021-08-12 11:14   ` Metzger, Markus T
2022-05-06 11:26     ` Willgerodt, Felix
2021-06-16  7:41 ` [PATCH v3 04/12] btrace: Handle stepping and goto for auxiliary instructions Felix Willgerodt
2021-08-12 11:07   ` Metzger, Markus T
2022-05-06 11:26     ` Willgerodt, Felix
2021-06-16  7:41 ` [PATCH v3 05/12] python: Introduce gdb.RecordAuxiliary class Felix Willgerodt
2021-08-12 11:07   ` Metzger, Markus T
2022-05-06 11:26     ` Willgerodt, Felix
2021-06-16  7:41 ` [PATCH v3 06/12] python: Add clear() to gdb.Record Felix Willgerodt
2021-08-12 11:07   ` Metzger, Markus T
2021-06-16  7:42 ` [PATCH v3 07/12] btrace, gdbserver: Add ptwrite to btrace_config_pt Felix Willgerodt
2021-08-12 11:07   ` Metzger, Markus T
2022-05-06 11:26     ` Willgerodt, Felix
2022-05-10 13:59       ` Metzger, Markus T
2022-06-24  6:57         ` Willgerodt, Felix
2021-06-16  7:42 ` [PATCH v3 08/12] btrace, linux: Enable ptwrite packets Felix Willgerodt
2021-08-12 11:07   ` Metzger, Markus T
2021-06-16  7:42 ` [PATCH v3 09/12] btrace, python: Enable ptwrite listener registration Felix Willgerodt
2021-08-13 10:36   ` Metzger, Markus T
2022-05-06 11:26     ` Willgerodt, Felix
2022-05-30 14:55       ` Metzger, Markus T
2022-05-31 11:26         ` Willgerodt, Felix
2022-05-31 11:50           ` Eli Zaretskii
2021-06-16  7:42 ` [PATCH v3 10/12] btrace, python: Enable calling the ptwrite listener Felix Willgerodt
2021-08-13 10:36   ` Metzger, Markus T
2022-05-06 11:26     ` Willgerodt, Felix
2022-05-30 15:01       ` Metzger, Markus T
2021-06-16  7:42 ` [PATCH v3 11/12] gdb, testsuite, lib: Add libipt version check Felix Willgerodt
2021-08-13 10:36   ` Metzger, Markus T
2022-05-02  9:55     ` Willgerodt, Felix
2021-06-16  7:42 ` [PATCH v3 12/12] btrace: Extend ptwrite event decoding Felix Willgerodt
2021-06-17  7:00   ` Eli Zaretskii
2021-06-17 11:51     ` Willgerodt, Felix
2021-08-13 13:36   ` Metzger, Markus T [this message]
2022-05-06 11:26     ` Willgerodt, Felix

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