qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 13/54] plugin: add user-facing API


From: Alex Bennée
Subject: Re: [Qemu-devel] [PATCH v4 13/54] plugin: add user-facing API
Date: Tue, 10 Sep 2019 18:41:40 +0100
User-agent: mu4e 1.3.4; emacs 27.0.50

Aaron Lindsay OS <address@hidden> writes:

> On Sep 06 20:31, Alex Bennée wrote:
>> Aaron Lindsay OS <address@hidden> writes:
>>
>> > One thing I would find useful is the ability to access register values
>> > during an execution-time callback. I think the easiest way to do that
>> > generically would be to expose them via the gdb functionality (like
>> > Pavel's earlier patchset did [1]), though that (currently) limits you to
>> > the general-purpose registers. Ideally it would be nice be able to
>> > access other registers (i.e. floating-point, or maybe even system
>> > registers), though those are more difficult to do generically.
>>
>> ARM already has system register support via the gdbstub XML interface so
>> it's certainly doable. The trick is how we do that in a probable way
>> without leaking the gdb remote protocol into plugins (which is just very
>> ugly).
>
> What do you mean by "in a probable way"?
>
> I agree that simply exposing the gdb interface does not seem like a
> clean solution.

That was a typo - portable was what I was aiming for. The problem with
the gdb interface is how you tie register id's to something useful
rather than having to encode the arbitrary gdb register enumeration into
your plugins.

>
>> > Perhaps if we added some sort of architectural-support checking for
>> > individual plugins like I mentioned in another response to this
>> > patchset, we could allow some limited architecture-specific
>> > functionality in this vein? I confess I haven't thought through all the
>> > ramifications of that yet, though.
>>
>> I was wondering if exposing the Elf Type would be enough? It's portable
>> enough that plugins should be able to work with it without defining our
>> own architecture enumeration.
>
> I can't think of a reason that wouldn't work, assuming you're referring
> to exposing a value corresponding to the `e_machine` ELF header.

Yes exactly that - I started but uncovered some hideousness in our
current Elf support so there will be a short diversion to re-factor that
into something a bit more usable across the code base.

>
> -Aaron


--
Alex Bennée



reply via email to

[Prev in Thread] Current Thread [Next in Thread]