qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Richard Henderson <richard.henderson@linaro.org>
To: Pierrick Bouvier <pierrick.bouvier@linaro.org>, qemu-devel@nongnu.org
Subject: Re: [PATCH 0/7] plugins: Use unwind info for special gdb registers
Date: Tue, 16 Apr 2024 19:40:10 -0700	[thread overview]
Message-ID: <91735cdb-0620-4fc6-a19d-08ca29acd9ff@linaro.org> (raw)
In-Reply-To: <c55a1d2c-bae0-44b5-9cd8-3df1b33c31ad@linaro.org>

On 4/16/24 17:35, Pierrick Bouvier wrote:
> On 4/15/24 21:06, Richard Henderson wrote:
>> Based-on: 20240404230611.21231-1-richard.henderson@linaro.org
>> ("[PATCH v2 00/21] Rewrite plugin code generation")
>>
>> This is an attempt to fix
>> https://gitlab.com/qemu-project/qemu/-/issues/2208
>> ("PC is not updated for each instruction in TCG plugins")
>>
>> I have only updated target/i386 so far, but basically all targets
>> need updating for the new callbacks.  Extra points to anyone who
>> sees how to avoid the extra code duplication.  :-)
>>
> 
> Thanks for the series Richard. It looks good to me.
> 
> Besides reviewing individual commits, I have a more general question.
>  From some discussions we had, it seems like that previously gdb stub was correctly 
> updating all register values, and that it has been dropped at some point.

Normally gdbstub does not run in the middle of a TB -- we end normally (single-step, 
breakpoint) or raise an exception (watchpoint).  Only then, after TCG state has been made 
consistent, does gdbstub have access to the CPUState.


> Was it for performance reasons, or an architectural change in QEMU?
> Is gdb stub the right way to poke register values for plugins?
> 
> I don't know exactly why some registers are not updated correctly in this context, but it 
> seems like we are trying to fix this afterward, instead of identifying root cause.

The one or two registers are not updated continuously for performance reasons.  And 
because they are not updated during initial code generation, it's not easy to do so later 
with plugin injection.  But recovering that data is what the unwind info is for -- a bit 
expensive to access that way, but overall less, with the expectation that it is rare.


r~


  reply	other threads:[~2024-04-17  2:41 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-16  4:06 [PATCH 0/7] plugins: Use unwind info for special gdb registers Richard Henderson
2024-04-16  4:06 ` [PATCH 1/7] tcg: Introduce INDEX_op_plugin_pc Richard Henderson
2024-04-18 17:53   ` Pierrick Bouvier
2024-04-16  4:06 ` [PATCH 2/7] accel/tcg: Set CPUState.plugin_ra before all plugin callbacks Richard Henderson
2024-04-18 17:54   ` Pierrick Bouvier
2024-05-31 16:46   ` Alex Bennée
2024-04-16  4:06 ` [PATCH 3/7] accel/tcg: Return the TranslationBlock from cpu_unwind_state_data Richard Henderson
2024-04-18 17:54   ` Pierrick Bouvier
2024-05-31 16:52   ` Alex Bennée
2024-04-16  4:06 ` [PATCH 4/7] plugins: Introduce TCGCPUOps callbacks for mid-tb register reads Richard Henderson
2024-04-18 17:55   ` Pierrick Bouvier
2024-04-16  4:06 ` [PATCH 5/7] target/i386: Split out gdb-internal.h Richard Henderson
2024-04-18 17:55   ` Pierrick Bouvier
2024-05-31 17:00   ` Alex Bennée
2024-04-16  4:06 ` [PATCH 6/7] target/i386: Introduce cpu_compute_eflags_ccop Richard Henderson
2024-04-18 17:56   ` Pierrick Bouvier
2024-04-16  4:06 ` [PATCH 7/7] target/i386: Implement TCGCPUOps for plugin register reads Richard Henderson
2024-04-18 17:56   ` Pierrick Bouvier
2024-04-17  0:35 ` [PATCH 0/7] plugins: Use unwind info for special gdb registers Pierrick Bouvier
2024-04-17  2:40   ` Richard Henderson [this message]
2024-04-17 15:39     ` Pierrick Bouvier
2024-04-22 16:49 ` Alex Bennée
  -- strict thread matches above, loose matches on Subject: below --
2024-04-16  4:05 Richard Henderson

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=91735cdb-0620-4fc6-a19d-08ca29acd9ff@linaro.org \
    --to=richard.henderson@linaro.org \
    --cc=pierrick.bouvier@linaro.org \
    --cc=qemu-devel@nongnu.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 NNTP newsgroup(s).