public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Andrew Burgess via Gdb-patches <gdb-patches@sourceware.org>
Cc: Andrew Burgess <aburgess@redhat.com>
Subject: Re: [PATCHv2] gdb/x86: handle stap probe arguments in xmm registers
Date: Wed, 16 Mar 2022 11:23:16 -0600	[thread overview]
Message-ID: <871qz1ke0r.fsf@tromey.com> (raw)
In-Reply-To: <20220316141316.465293-1-aburgess@redhat.com> (Andrew Burgess via Gdb-patches's message of "Wed, 16 Mar 2022 14:13:16 +0000")

>>>>> "Andrew" == Andrew Burgess via Gdb-patches <gdb-patches@sourceware.org> writes:

Andrew> Notice that for both of these probes, the first argument is a uint64_t
Andrew> stored in the xmm1 register.

I wonder how much the ideas in here overlap with Zoran's still-pending
patches to rework the DWARF expression evaluator.  IIUC his work
involved some of this same sort of extraction.  However, since yours is
via the stap probe stuff, there probably isn't much opportunity for code
reuse.

Andrew> architectures this method would fist possibly adjust the register

fist->first

Andrew> Finally, as this patch adds a new operation type, then I need to
Andrew> consider how to generate an agent expression for the new operation
Andrew> type.

Andrew> I have kicked the can down the road a bit on this.

This seems completely fine to me.

Andrew> This is because GDB doesn't currently support placing non-scalar types
Andrew> on the agent expression evaluation stack.  Solving this is clearly
Andrew> related to the original problem, but feels a bit like a second
Andrew> problem.  I'd like to get feedback on whether my approach to solving
Andrew> the original problem is acceptable or not before I start looking at
Andrew> how to handle xmm registers within agent expressions.

Note that there are many things that can't be represented in agent
expressions.  I recall filing a bug report about this -- there are some
DWARF expressions that can't be translated, and IIRC, floating point
isn't handled at all.  So, I wouldn't worry too much about this.  My
sense is that tracepoints aren't used a whole lot.

Anyway your patch looked reasonable to me.

Tom

  reply	other threads:[~2022-03-16 17:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-15 10:54 [PATCH] " Andrew Burgess
2022-03-15 13:53 ` Metzger, Markus T
2022-03-15 17:28   ` Andrew Burgess
2022-03-16  9:36     ` Metzger, Markus T
2022-03-16 10:03       ` Andrew Burgess
2022-03-16 10:29         ` Metzger, Markus T
2022-03-16 14:13 ` [PATCHv2] " Andrew Burgess
2022-03-16 17:23   ` Tom Tromey [this message]
2022-03-17 15:54     ` Pedro Alves
2022-03-21 14:41       ` Andrew Burgess
2022-03-16 17:42   ` Tom Tromey

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=871qz1ke0r.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=aburgess@redhat.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).