[Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[=?gb18030?B?waI=?=]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 709 bytes --]

I am working on a project that requires me to modify the ISA of the MIPS target. I have been staring at the source code for about a week, but found it really difficult due to me being a young rookie and the sparse comments.
Specifically, I need to extend MIPS, by adding some new instructions and new CPU registers to the current architecture, and that sounds really easy. I think the place for me to look at should be at the directory ${qemu_root}/target/mips/. With a MIPS Instruction Set Manual Release 6 handy, I have difficulty finding the source code where the ISA resides. Is it in op_helper.c? Or translate.c? Any guidance would be really appreciated. Thank you very much in advance.


Cheers,
L.

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[Peter Maydell]

On Tue, 20 Aug 2019 at 11:12, 立 <zhlb29@foxmail.com> wrote:
>
> I am working on a project that requires me to modify the ISA of the MIPS target. I have been staring at the source code for about a week, but found it really difficult due to me being a young rookie and the sparse comments.
> Specifically, I need to extend MIPS, by adding some new instructions and new CPU registers to the current architecture, and that sounds really easy. I think the place for me to look at should be at the directory ${qemu_root}/target/mips/. With a MIPS Instruction Set Manual Release 6 handy, I have difficulty finding the source code where the ISA resides. Is it in op_helper.c? Or translate.c? Any guidance would be really appreciated. Thank you very much in advance.

The general structure of a QEMU target front-end is that
there is a 'decoder', typically in translate.c, which
takes target instructions, figures out what they are,
and emits TCG operations (an intermediate representation)
for them. Sometimes a guest instruction is simple and
can be handled by directly generating TCG code to do
it. Some instructions are more complex, and we handle
them by generating TCG code which will at runtime call
a helper function to do the bulk of the work. Those
helpers (and some other code, like code to handle TLB
misses and various exceptions) lives in the various
helper.c files.

One important concept to be clear on is that QEMU is
a JIT -- this means that we generate host code that
corresponds to target code (at "translate time"), and
then later we will run the host code (at "run time");
code generated once can be run many times. You need
to be clear about whether QEMU C code you're looking at
is called at translate time or at run time, because
the things that you can do are very different.

thanks
-- PMM

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[Aleksandar Markovic]

On Tue, Aug 20, 2019 at 12:12 PM 立 <zhlb29@foxmail.com> wrote:

> I am working on a project that requires me to modify the ISA of the MIPS
> target. I have been staring at the source code for about a week, but found
> it really difficult due to me being a young rookie and the sparse comments.
> Specifically, I need to extend MIPS, by adding some new instructions and
> new CPU registers to the current architecture, and that sounds really easy.
> I think the place for me to look at should be at the directory
> ${qemu_root}/target/mips/. With a MIPS Instruction Set Manual Release 6
> handy, I have difficulty finding the source code where the ISA resides. Is
> it in op_helper.c? Or translate.c? Any guidance would be really
> appreciated. Thank you very much in advance.
>
>
Let's say you want to add a new instruction to an ISA.

First, you need to define the layout of the binary code for that
instruction. This means some of the bits would determine registers that
contain input and output values for that instruction, and some of the bits
would be the ID (or, some would say, opcode) for that instruction. Perhaps
some other stuff to can be included here.

Once you settle the binary layout, you need to properly decode that
instruction, in one of many switch statements in translate.c.

After that, the main body of your work begin, You need to implement the
functionality you desire. There are two ways. If your functionality is
simple, as a rule, you would implement it using so called TCG (this is
just-in-time compiler inside QEMU). If your functionality is more complex,
you would implement it using C-functions called helpers. Those helpers
usually reside in op_helper.c, while TCG implementation usually reside
within translate.c.

After all this, you need to write a test program (that would be a little
tricky, since your new instruction will not be recognized by the compiler),
and execute it using QEMU.

I wish you an interesting journey into emulation!

Yours,
Aleksandar







>
> Cheers,
> L.

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[Aleksandar Markovic]

On Tue, Aug 20, 2019 at 12:12 PM 立 <zhlb29@foxmail.com> wrote:

> I am working on a project that requires me to modify the ISA of the MIPS
> target.


L.,

How is it going?

Aleksandar



> I have been staring at the source code for about a week, but found it
> really difficult due to me being a young rookie and the sparse comments.
> Specifically, I need to extend MIPS, by adding some new instructions and
> new CPU registers to the current architecture, and that sounds really easy.
> I think the place for me to look at should be at the directory
> ${qemu_root}/target/mips/. With a MIPS Instruction Set Manual Release 6
> handy, I have difficulty finding the source code where the ISA resides. Is
> it in op_helper.c? Or translate.c? Any guidance would be really
> appreciated. Thank you very much in advance.
>
>
> Cheers,
> L.

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[=?gb18030?B?waI=?=]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 1787 bytes --]

Hi Aleksandar,


Thank you very much for your patient explanation in the previous post. And thank you for checking.
Your and Peter's replies in the previous post certainly helped a lot. I am now looking at a git commit 7 years ago (bd277fa1966bc400f1b411f868f39125cda0c403), it was a Loongson Multimedia Instruction implementation done my Richard Henderson. I think what he did is exactly what I want to do now. I got a vague view of the big picture, but I need more time to figure out the details. I will certainly ask more questions about this later, but before that I need to look at some other parts of the source code:) Again thank you for checking!



Cheers,
Libo





------------------ Original message ------------------
From: "Aleksandar Markovic"; 
Sendtime: Thursday, Aug 22, 2019 4:23 PM
To: "Á¢"; 
Cc: "qemu-devel"; 
Subject: Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)



On Tue, Aug 20, 2019 at 12:12 PM Á¢ <zhlb29@foxmail.com> wrote:

> I am working on a project that requires me to modify the ISA of the MIPS
> target.


L.,

How is it going?

Aleksandar



> I have been staring at the source code for about a week, but found it
> really difficult due to me being a young rookie and the sparse comments.
> Specifically, I need to extend MIPS, by adding some new instructions and
> new CPU registers to the current architecture, and that sounds really easy.
> I think the place for me to look at should be at the directory
> ${qemu_root}/target/mips/. With a MIPS Instruction Set Manual Release 6
> handy, I have difficulty finding the source code where the ISA resides. Is
> it in op_helper.c? Or translate.c? Any guidance would be really
> appreciated. Thank you very much in advance.
>
>
> Cheers,
> L.

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[Aleksandar Markovic]

On Thu, Aug 22, 2019 at 12:24 PM 立 <zhlb29@foxmail.com> wrote:

> Hi Aleksandar,
>
> Thank you very much for your patient explanation in the previous post. And
> thank you for checking.
> Your and Peter's replies in the previous post certainly helped a lot. I am
> now looking at a git commit 7 years ago (
> bd277fa1966bc400f1b411f868f39125cda0c403), it was a Loongson Multimedia
> Instruction implementation done my Richard Henderson.
>

Cool, that commit is a very good staring point - it is definitely not too
simple, and it is not too complex either. And you can discover several
different concepts in the process of exploring the change.

Documentation on instruction set extension related to the commit (found by
Google):
https://files.somniafabularum.com/loongson/docs/Loongson2FUserGuide.pdf

Be persistent, take your time, study the details and handling of individual
instructions, and, of course, let us know if you encounter some major
obstacles or thorny dilemmas.

Yours,
Aleksandar


> I think what he did is exactly what I want to do now. I got a vague view
> of the big picture, but I need more time to figure out the details. I will
> certainly ask more questions about this later, but before that I need to
> look at some other parts of the source code:) Again thank you for checking!
>
> Cheers,
> Libo
>
>
> ------------------ Original message ------------------
> *From:* "Aleksandar Markovic";
> *Sendtime:* Thursday, Aug 22, 2019 4:23 PM
> *To:* "立";
> *Cc:* "qemu-devel";
> *Subject:* Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
>
> On Tue, Aug 20, 2019 at 12:12 PM 立 <zhlb29@foxmail.com> wrote:
>
> > I am working on a project that requires me to modify the ISA of the MIPS
> > target.
>
>
> L.,
>
> How is it going?
>
> Aleksandar
>
>
>
> > I have been staring at the source code for about a week, but found it
> > really difficult due to me being a young rookie and the sparse comments.
> > Specifically, I need to extend MIPS, by adding some new instructions and
> > new CPU registers to the current architecture, and that sounds really
> easy.
> > I think the place for me to look at should be at the directory
> > ${qemu_root}/target/mips/. With a MIPS Instruction Set Manual Release 6
> > handy, I have difficulty finding the source code where the ISA resides.
> Is
> > it in op_helper.c? Or translate.c? Any guidance would be really
> > appreciated. Thank you very much in advance.
> >
> >
> > Cheers,
> > L.
>

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[=?gb18030?B?TGlibyBaaG91?=]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 3505 bytes --]

Hi Aleksandar,


Thank you for the link to Loongson2F documentation. It has been very useful:)


I have spent several days immersing myself in the source code, now I think I have a more solid understanding about it. Just like Loongson Multimedia Instructions, I need to implement some sort of complex vector instructions, and I need to write some helper functions (e.g. my_helper.c).


The QEMU wiki website has very thorough explanation on TCG, but I haven't found any explanation on the port-specific helpers. Is there any documentation on how the helper functions are generated? I think now I *might* know how to write a working helper function, but I just don't know how it works.


Cheers,
Libo









------------------ Original message ------------------
From: "Aleksandar Markovic"; 
Sendtime: Thursday, Aug 22, 2019 6:53 PM
To: "Libo Zhou"; 
Cc: "qemu-devel"; 
Subject: Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)



On Thu, Aug 22, 2019 at 12:24 PM Á¢ <zhlb29@foxmail.com> wrote:

> Hi Aleksandar,
>
> Thank you very much for your patient explanation in the previous post. And
> thank you for checking.
> Your and Peter's replies in the previous post certainly helped a lot. I am
> now looking at a git commit 7 years ago (
> bd277fa1966bc400f1b411f868f39125cda0c403), it was a Loongson Multimedia
> Instruction implementation done my Richard Henderson.
>

Cool, that commit is a very good staring point - it is definitely not too
simple, and it is not too complex either. And you can discover several
different concepts in the process of exploring the change.

Documentation on instruction set extension related to the commit (found by
Google):
https://files.somniafabularum.com/loongson/docs/Loongson2FUserGuide.pdf

Be persistent, take your time, study the details and handling of individual
instructions, and, of course, let us know if you encounter some major
obstacles or thorny dilemmas.

Yours,
Aleksandar


> I think what he did is exactly what I want to do now. I got a vague view
> of the big picture, but I need more time to figure out the details. I will
> certainly ask more questions about this later, but before that I need to
> look at some other parts of the source code:) Again thank you for checking!
>
> Cheers,
> Libo
>
>
> ------------------ Original message ------------------
> *From:* "Aleksandar Markovic";
> *Sendtime:* Thursday, Aug 22, 2019 4:23 PM
> *To:* "Á¢";
> *Cc:* "qemu-devel";
> *Subject:* Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
>
> On Tue, Aug 20, 2019 at 12:12 PM Á¢ <zhlb29@foxmail.com> wrote:
>
> > I am working on a project that requires me to modify the ISA of the MIPS
> > target.
>
>
> L.,
>
> How is it going?
>
> Aleksandar
>
>
>
> > I have been staring at the source code for about a week, but found it
> > really difficult due to me being a young rookie and the sparse comments.
> > Specifically, I need to extend MIPS, by adding some new instructions and
> > new CPU registers to the current architecture, and that sounds really
> easy.
> > I think the place for me to look at should be at the directory
> > ${qemu_root}/target/mips/. With a MIPS Instruction Set Manual Release 6
> > handy, I have difficulty finding the source code where the ISA resides.
> Is
> > it in op_helper.c? Or translate.c? Any guidance would be really
> > appreciated. Thank you very much in advance.
> >
> >
> > Cheers,
> > L.
>

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[Aleksandar Markovic]

On Wed, Aug 28, 2019 at 5:54 AM Libo Zhou <zhlb29@foxmail.com> wrote:

> Hi Aleksandar,
>
> Thank you for the link to Loongson2F documentation. It has been very
> useful:)
>
> I have spent several days immersing myself in the source code, now I think
> I have a more solid understanding about it. Just like Loongson Multimedia
> Instructions, I need to implement some sort of complex vector instructions,
> and I need to write some helper functions (e.g. my_helper.c).
>
> The QEMU wiki website has very thorough explanation on TCG, but I haven't
> found any explanation on the port-specific helpers. Is there any
> documentation on how the helper functions are generated? I think now I
> *might* know how to write a working helper function, but I just don't know
> how it works.
>
>
Hello, Libo,

Prerequisite for writing a helper is that you have a clear definition of
new instruction functionality, in the sense, what operation is done on what
resources. "Resources" are registers - they could be general-purpose MIPS
registers, or some special additional registers. Did you use existing
registers, or did you define a new set or registers for your new
instructions? Registers are modeled as fields in a structure, and both
helpers and TCG implementations modify those fields while performing
instruction emulation.

In any case, you pass to the helper all information needed for the
instruction in question to perform. These are usually ordinal numbers of
involved register, derived from decoding the opcode. Alternatively, you can
pass pointers to the registers, rather than ordinal numbers. In turn, the
main part of functionality is implemented. At the end of helper, you may
want to update, let's say, a status register, if any (depending on your
design).

The declaration of helpers is a little contrived, and may still confuse
you. But this is not crucial to you. I advise you just to copy a solution
for a similar existing instruction.

Yours,
Aleksandar



> Cheers,
> Libo
>
>
>
>
> ------------------ Original message ------------------
> *From:* "Aleksandar Markovic";
> *Sendtime:* Thursday, Aug 22, 2019 6:53 PM
> *To:* "Libo Zhou";
> *Cc:* "qemu-devel";
> *Subject:* Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
>
> On Thu, Aug 22, 2019 at 12:24 PM 立 <zhlb29@foxmail.com> wrote:
>
> > Hi Aleksandar,
> >
> > Thank you very much for your patient explanation in the previous post.
> And
> > thank you for checking.
> > Your and Peter's replies in the previous post certainly helped a lot. I
> am
> > now looking at a git commit 7 years ago (
> > bd277fa1966bc400f1b411f868f39125cda0c403), it was a Loongson Multimedia
> > Instruction implementation done my Richard Henderson.
> >
>
> Cool, that commit is a very good staring point - it is definitely not too
> simple, and it is not too complex either. And you can discover several
> different concepts in the process of exploring the change.
>
> Documentation on instruction set extension related to the commit (found by
> Google):
> https://files.somniafabularum.com/loongson/docs/Loongson2FUserGuide.pdf
>
> Be persistent, take your time, study the details and handling of individual
> instructions, and, of course, let us know if you encounter some major
> obstacles or thorny dilemmas.
>
> Yours,
> Aleksandar
>
>
> > I think what he did is exactly what I want to do now. I got a vague view
> > of the big picture, but I need more time to figure out the details. I
> will
> > certainly ask more questions about this later, but before that I need to
> > look at some other parts of the source code:) Again thank you for
> checking!
> >
> > Cheers,
> > Libo
> >
> >
> > ------------------ Original message ------------------
> > *From:* "Aleksandar Markovic";
> > *Sendtime:* Thursday, Aug 22, 2019 4:23 PM
> > *To:* "立";
> > *Cc:* "qemu-devel";
> > *Subject:* Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
> >
> > On Tue, Aug 20, 2019 at 12:12 PM 立 <zhlb29@foxmail.com> wrote:
> >
> > > I am working on a project that requires me to modify the ISA of the
> MIPS
> > > target.
> >
> >
> > L.,
> >
> > How is it going?
> >
> > Aleksandar
> >
> >
> >
> > > I have been staring at the source code for about a week, but found it
> > > really difficult due to me being a young rookie and the sparse
> comments.
> > > Specifically, I need to extend MIPS, by adding some new instructions
> and
> > > new CPU registers to the current architecture, and that sounds really
> > easy.
> > > I think the place for me to look at should be at the directory
> > > ${qemu_root}/target/mips/. With a MIPS Instruction Set Manual Release 6
> > > handy, I have difficulty finding the source code where the ISA resides.
> > Is
> > > it in op_helper.c? Or translate.c? Any guidance would be really
> > > appreciated. Thank you very much in advance.
> > >
> > >
> > > Cheers,
> > > L.
> >
>

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[=?gb18030?B?TGlibyBaaG91?=]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 7281 bytes --]

Hi Aleksandar,


Thanks for explaining  helper functions for me. Before getting my hands dirty, I have some more  questions. After figuring them out, I can get started.



I  need to add some new registers to the CPU. In "translate.c", I found  that the registers are declared as static TCGv array (e.g. cpu_gpr[32]).  Then, in function mips_tcg_init(), cpu_gpr[i] is created one by one  with tcg_global_mem_new(...) in a for loop. Is that all I need to do to  add new registers to the CPU? I noticed another file "cpu.h", do I also  need to add my new registers, say, "my_gpr[32]" in "cpu.h"?


My  new instructions also include some load & stores. I see I can  implement them with tcg_gen_qemu_ld/st_tl(...) in the decode function's  switch-case statements, but I don't see how the *target* memory is  created. Shouldn't they be created with tcg_global_mem_new(...), just  like how the registers are created? I can hack the memory by creating a  *super* larger register file, and hack the loads & stores with  register moves, but that just sounds too sketchy.


On  the other hand, I would like to get it running first, without doing any  modification to the source code. I can build the user space emulation  on Linux.

./configure --target-list=mips-linux-user

Then  I will write a testprogram.c, cross compile it on x86 into MIPS using  gcc(I am not clear on how to do it, but my team has the compiler for our  new ISA, I just want to try the MIPS version first), and run the test  program.



./qemu testprogram


How  do I look at the contents in the target registers and memory? I saw  that function "mips_cpu_dump_state" in "translate.c" does what I need,  but I don't know how to call it in this process. Should I use gdb?


I  am really sorry for asking you so many questions, but I think after  getting them figured out, I can start my project. Thank you very much in  advance, and have a good weekend!


Cheers,

Libo



------------------ Original ------------------
From:  "Aleksandar Markovic";<aleksandar.m.mail@gmail.com>;
Send time: Thursday, Aug 29, 2019 10:22 PM
To: "Libo Zhou"<zhlb29@foxmail.com>; 
Cc: "qemu-devel"<qemu-devel@nongnu.org>; 
Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)



On Wed, Aug 28, 2019 at 5:54 AM Libo Zhou <zhlb29@foxmail.com> wrote:

> Hi Aleksandar,
>
> Thank you for the link to Loongson2F documentation. It has been very
> useful:)
>
> I have spent several days immersing myself in the source code, now I think
> I have a more solid understanding about it. Just like Loongson Multimedia
> Instructions, I need to implement some sort of complex vector instructions,
> and I need to write some helper functions (e.g. my_helper.c).
>
> The QEMU wiki website has very thorough explanation on TCG, but I haven't
> found any explanation on the port-specific helpers. Is there any
> documentation on how the helper functions are generated? I think now I
> *might* know how to write a working helper function, but I just don't know
> how it works.
>
>
Hello, Libo,

Prerequisite for writing a helper is that you have a clear definition of
new instruction functionality, in the sense, what operation is done on what
resources. "Resources" are registers - they could be general-purpose MIPS
registers, or some special additional registers. Did you use existing
registers, or did you define a new set or registers for your new
instructions? Registers are modeled as fields in a structure, and both
helpers and TCG implementations modify those fields while performing
instruction emulation.

In any case, you pass to the helper all information needed for the
instruction in question to perform. These are usually ordinal numbers of
involved register, derived from decoding the opcode. Alternatively, you can
pass pointers to the registers, rather than ordinal numbers. In turn, the
main part of functionality is implemented. At the end of helper, you may
want to update, let's say, a status register, if any (depending on your
design).

The declaration of helpers is a little contrived, and may still confuse
you. But this is not crucial to you. I advise you just to copy a solution
for a similar existing instruction.

Yours,
Aleksandar



> Cheers,
> Libo
>
>
>
>
> ------------------ Original message ------------------
> *From:* "Aleksandar Markovic";
> *Sendtime:* Thursday, Aug 22, 2019 6:53 PM
> *To:* "Libo Zhou";
> *Cc:* "qemu-devel";
> *Subject:* Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
>
> On Thu, Aug 22, 2019 at 12:24 PM Á¢ <zhlb29@foxmail.com> wrote:
>
> > Hi Aleksandar,
> >
> > Thank you very much for your patient explanation in the previous post.
> And
> > thank you for checking.
> > Your and Peter's replies in the previous post certainly helped a lot. I
> am
> > now looking at a git commit 7 years ago (
> > bd277fa1966bc400f1b411f868f39125cda0c403), it was a Loongson Multimedia
> > Instruction implementation done my Richard Henderson.
> >
>
> Cool, that commit is a very good staring point - it is definitely not too
> simple, and it is not too complex either. And you can discover several
> different concepts in the process of exploring the change.
>
> Documentation on instruction set extension related to the commit (found by
> Google):
> https://files.somniafabularum.com/loongson/docs/Loongson2FUserGuide.pdf
>
> Be persistent, take your time, study the details and handling of individual
> instructions, and, of course, let us know if you encounter some major
> obstacles or thorny dilemmas.
>
> Yours,
> Aleksandar
>
>
> > I think what he did is exactly what I want to do now. I got a vague view
> > of the big picture, but I need more time to figure out the details. I
> will
> > certainly ask more questions about this later, but before that I need to
> > look at some other parts of the source code:) Again thank you for
> checking!
> >
> > Cheers,
> > Libo
> >
> >
> > ------------------ Original message ------------------
> > *From:* "Aleksandar Markovic";
> > *Sendtime:* Thursday, Aug 22, 2019 4:23 PM
> > *To:* "Á¢";
> > *Cc:* "qemu-devel";
> > *Subject:* Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
> >
> > On Tue, Aug 20, 2019 at 12:12 PM Á¢ <zhlb29@foxmail.com> wrote:
> >
> > > I am working on a project that requires me to modify the ISA of the
> MIPS
> > > target.
> >
> >
> > L.,
> >
> > How is it going?
> >
> > Aleksandar
> >
> >
> >
> > > I have been staring at the source code for about a week, but found it
> > > really difficult due to me being a young rookie and the sparse
> comments.
> > > Specifically, I need to extend MIPS, by adding some new instructions
> and
> > > new CPU registers to the current architecture, and that sounds really
> > easy.
> > > I think the place for me to look at should be at the directory
> > > ${qemu_root}/target/mips/. With a MIPS Instruction Set Manual Release 6
> > > handy, I have difficulty finding the source code where the ISA resides.
> > Is
> > > it in op_helper.c? Or translate.c? Any guidance would be really
> > > appreciated. Thank you very much in advance.
> > >
> > >
> > > Cheers,
> > > L.
> >
>

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[Aleksandar Markovic]

30.08.2019. 11.14, "Libo Zhou" <zhlb29@foxmail.com> је написао/ла:
>
> Hi Aleksandar,
>
> Thanks for explaining helper functions for me. Before getting my hands
dirty, I have some more questions. After figuring them out, I can get
started.
>
> I need to add some new registers to the CPU. In "translate.c", I found
that the registers are declared as static TCGv array (e.g. cpu_gpr[32]).
Then, in function mips_tcg_init(), cpu_gpr[i] is created one by one with
tcg_global_mem_new(...) in a for loop. Is that all I need to do to add new
registers to the CPU? I noticed another file "cpu.h", do I also need to add
my new registers, say, "my_gpr[32]" in "cpu.h"?
>
> My new instructions also include some load & stores. I see I can
implement them with tcg_gen_qemu_ld/st_tl(...) in the decode function's
switch-case statements, but I don't see how the *target* memory is created.
Shouldn't they be created with tcg_global_mem_new(...), just like how the
registers are created? I can hack the memory by creating a *super* larger
register file, and hack the loads & stores with register moves, but that
just sounds too sketchy.
>

For register definition, load/store instruction, take a look at details of
this series:

https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg06028.html

Don't mix register and memory initialization. For memory, the existing code
should bu sufficient.

What you need to additionally do (and you didn't mention it) is to define a
CPU that will have some base instruction set (it coukd be, for example,
mips32r2) + your additional instructions. This is done in file by adding a
corresponding item in translate_init.inc.c (if you choise mips32r2 as base
ISA, you could base your new CPU on existing CPU 24Kf). And then you start
QEMU with switch "-cpu <your newly defined CPU>".

I may add more explanation later on.

> On the other hand, I would like to get it running first, without doing
any modification to the source code. I can build the user space emulation
on Linux.
>
> ./configure --target-list=mips-linux-user
>
> Then I will write a testprogram.c, cross compile it on x86 into MIPS
using gcc(I am not clear on how to do it, but my team has the compiler for
our new ISA, I just want to try the MIPS version first), and run the test
program.
>
> ./qemu testprogram
>
> How do I look at the contents in the target registers and memory? I saw
that function "mips_cpu_dump_state" in "translate.c" does what I need, but
I don't know how to call it in this process. Should I use gdb?
>
> I am really sorry for asking you so many questions, but I think after
getting them figured out, I can start my project. Thank you very much in
advance, and have a good weekend!
>

The questions are always fine and welcome, just we are typically very busy,
snd can't always promptly replay.

Aleksandae

> Cheers,
> Libo
>
>
> ------------------ Original ------------------
> From:  "Aleksandar Markovic";<aleksandar.m.mail@gmail.com>;
> Send time: Thursday, Aug 29, 2019 10:22 PM
> To: "Libo Zhou"<zhlb29@foxmail.com>;
> Cc: "qemu-devel"<qemu-devel@nongnu.org>;
> Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
>
> On Wed, Aug 28, 2019 at 5:54 AM Libo Zhou <zhlb29@foxmail.com> wrote:
>
> > Hi Aleksandar,
> >
> > Thank you for the link to Loongson2F documentation. It has been very
> > useful:)
> >
> > I have spent several days immersing myself in the source code, now I
think
> > I have a more solid understanding about it. Just like Loongson
Multimedia
> > Instructions, I need to implement some sort of complex vector
instructions,
> > and I need to write some helper functions (e.g. my_helper.c).
> >
> > The QEMU wiki website has very thorough explanation on TCG, but I
haven't
> > found any explanation on the port-specific helpers. Is there any
> > documentation on how the helper functions are generated? I think now I
> > *might* know how to write a working helper function, but I just don't
know
> > how it works.
> >
> >
> Hello, Libo,
>
> Prerequisite for writing a helper is that you have a clear definition of
> new instruction functionality, in the sense, what operation is done on
what
> resources. "Resources" are registers - they could be general-purpose MIPS
> registers, or some special additional registers. Did you use existing
> registers, or did you define a new set or registers for your new
> instructions? Registers are modeled as fields in a structure, and both
> helpers and TCG implementations modify those fields while performing
> instruction emulation.
>
> In any case, you pass to the helper all information needed for the
> instruction in question to perform. These are usually ordinal numbers of
> involved register, derived from decoding the opcode. Alternatively, you
can
> pass pointers to the registers, rather than ordinal numbers. In turn, the
> main part of functionality is implemented. At the end of helper, you may
> want to update, let's say, a status register, if any (depending on your
> design).
>
> The declaration of helpers is a little contrived, and may still confuse
> you. But this is not crucial to you. I advise you just to copy a solution
> for a similar existing instruction.
>
> Yours,
> Aleksandar
>
>
>
> > Cheers,
> > Libo
> >
> >
> >
> >
> > ------------------ Original message ------------------
> > *From:* "Aleksandar Markovic";
> > *Sendtime:* Thursday, Aug 22, 2019 6:53 PM
> > *To:* "Libo Zhou";
> > *Cc:* "qemu-devel";
> > *Subject:* Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
> >
> > On Thu, Aug 22, 2019 at 12:24 PM 立 <zhlb29@foxmail.com> wrote:
> >
> > > Hi Aleksandar,
> > >
> > > Thank you very much for your patient explanation in the previous post.
> > And
> > > thank you for checking.
> > > Your and Peter's replies in the previous post certainly helped a lot.
I
> > am
> > > now looking at a git commit 7 years ago (
> > > bd277fa1966bc400f1b411f868f39125cda0c403), it was a Loongson
Multimedia
> > > Instruction implementation done my Richard Henderson.
> > >
> >
> > Cool, that commit is a very good staring point - it is definitely not
too
> > simple, and it is not too complex either. And you can discover several
> > different concepts in the process of exploring the change.
> >
> > Documentation on instruction set extension related to the commit (found
by
> > Google):
> > https://files.somniafabularum.com/loongson/docs/Loongson2FUserGuide.pdf
> >
> > Be persistent, take your time, study the details and handling of
individual
> > instructions, and, of course, let us know if you encounter some major
> > obstacles or thorny dilemmas.
> >
> > Yours,
> > Aleksandar
> >
> >
> > > I think what he did is exactly what I want to do now. I got a vague
view
> > > of the big picture, but I need more time to figure out the details. I
> > will
> > > certainly ask more questions about this later, but before that I need
to
> > > look at some other parts of the source code:) Again thank you for
> > checking!
> > >
> > > Cheers,
> > > Libo
> > >
> > >
> > > ------------------ Original message ------------------
> > > *From:* "Aleksandar Markovic";
> > > *Sendtime:* Thursday, Aug 22, 2019 4:23 PM
> > > *To:* "立";
> > > *Cc:* "qemu-devel";
> > > *Subject:* Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
> > >
> > > On Tue, Aug 20, 2019 at 12:12 PM 立 <zhlb29@foxmail.com> wrote:
> > >
> > > > I am working on a project that requires me to modify the ISA of the
> > MIPS
> > > > target.
> > >
> > >
> > > L.,
> > >
> > > How is it going?
> > >
> > > Aleksandar
> > >
> > >
> > >
> > > > I have been staring at the source code for about a week, but found
it
> > > > really difficult due to me being a young rookie and the sparse
> > comments.
> > > > Specifically, I need to extend MIPS, by adding some new instructions
> > and
> > > > new CPU registers to the current architecture, and that sounds
really
> > > easy.
> > > > I think the place for me to look at should be at the directory
> > > > ${qemu_root}/target/mips/. With a MIPS Instruction Set Manual
Release 6
> > > > handy, I have difficulty finding the source code where the ISA
resides.
> > > Is
> > > > it in op_helper.c? Or translate.c? Any guidance would be really
> > > > appreciated. Thank you very much in advance.
> > > >
> > > >
> > > > Cheers,
> > > > L.
> > >
> >

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[Libo Zhou]

Hi Aleksandar,


I have spent some time looking at your MXU ASE patch. It's super helpful. I need to do exactly the same thing as you did.


Now I just need a way to observe the memory and register file contents to debug my instruction set simulator. I played with the "-d" switch to log a bunch of information, but it seems that none of the items is of my interest. The "-d cpu_reset" option displays all zeros in the GPR log.



Please take your time, as I fully understand you need to work on Qemu while answering all my questions. Again, thank you very much for your help!



Cheers,
Libo



------------------ Original ------------------
From:  "Aleksandar Markovic";<aleksandar.m.mail@gmail.com>;
Send time: Tuesday, Sep 3, 2019 3:07 PM
To: "Libo Zhou"<zhlb29@foxmail.com>; 
Cc: "qemu-devel"<qemu-devel@nongnu.org>; 
Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)



30.08.2019. 11.14, "Libo Zhou" <zhlb29@foxmail.com> wrote:
>
> Hi Aleksandar,
>
> Thanks for explaining helper functions for me. Before getting my hands
dirty, I have some more questions. After figuring them out, I can get
started.
>
> I need to add some new registers to the CPU. In "translate.c", I found
that the registers are declared as static TCGv array (e.g. cpu_gpr[32]).
Then, in function mips_tcg_init(), cpu_gpr[i] is created one by one with
tcg_global_mem_new(...) in a for loop. Is that all I need to do to add new
registers to the CPU? I noticed another file "cpu.h", do I also need to add
my new registers, say, "my_gpr[32]" in "cpu.h"?
>
> My new instructions also include some load & stores. I see I can
implement them with tcg_gen_qemu_ld/st_tl(...) in the decode function's
switch-case statements, but I don't see how the *target* memory is created.
Shouldn't they be created with tcg_global_mem_new(...), just like how the
registers are created? I can hack the memory by creating a *super* larger
register file, and hack the loads & stores with register moves, but that
just sounds too sketchy.
>

For register definition, load/store instruction, take a look at details of
this series:

https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg06028.html

Don't mix register and memory initialization. For memory, the existing code
should be sufficient.

What you need to additionally do (and you didn't mention it) is to define a
CPU that will have some base instruction set (it could be, for example,
mips32r2) + your additional instructions. This is done in file by adding a
corresponding item in translate_init.inc.c (if you choose mips32r2 as base
ISA, you could base your new CPU on existing CPU 24Kf). And then you start
QEMU with switch "-cpu <your newly defined CPU>".

I may add more explanation later on.

> On the other hand, I would like to get it running first, without doing
any modification to the source code. I can build the user space emulation
on Linux.
>
> ./configure --target-list=mips-linux-user
>
> Then I will write a testprogram.c, cross compile it on x86 into MIPS
using gcc(I am not clear on how to do it, but my team has the compiler for
our new ISA, I just want to try the MIPS version first), and run the test
program.
>
> ./qemu testprogram
>
> How do I look at the contents in the target registers and memory? I saw
that function "mips_cpu_dump_state" in "translate.c" does what I need, but
I don't know how to call it in this process. Should I use gdb?
>
> I am really sorry for asking you so many questions, but I think after
getting them figured out, I can start my project. Thank you very much in
advance, and have a good weekend!
>

The questions are always fine and welcome, just we are typically very busy,
and can't always promptly reply.

Aleksandar

> Cheers,
> Libo
>
>
> ------------------ Original ------------------
> From:  "Aleksandar Markovic";<aleksandar.m.mail@gmail.com>;
> Send time: Thursday, Aug 29, 2019 10:22 PM
> To: "Libo Zhou"<zhlb29@foxmail.com>;
> Cc: "qemu-devel"<qemu-devel@nongnu.org>;
> Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
>
> On Wed, Aug 28, 2019 at 5:54 AM Libo Zhou <zhlb29@foxmail.com> wrote:
>
> > Hi Aleksandar,
> >
> > Thank you for the link to Loongson2F documentation. It has been very
> > useful:)
> >
> > I have spent several days immersing myself in the source code, now I
think
> > I have a more solid understanding about it. Just like Loongson
Multimedia
> > Instructions, I need to implement some sort of complex vector
instructions,
> > and I need to write some helper functions (e.g. my_helper.c).
> >
> > The QEMU wiki website has very thorough explanation on TCG, but I
haven't
> > found any explanation on the port-specific helpers. Is there any
> > documentation on how the helper functions are generated? I think now I
> > *might* know how to write a working helper function, but I just don't
know
> > how it works.
> >
> >
> Hello, Libo,
>
> Prerequisite for writing a helper is that you have a clear definition of
> new instruction functionality, in the sense, what operation is done on
what
> resources. "Resources" are registers - they could be general-purpose MIPS
> registers, or some special additional registers. Did you use existing
> registers, or did you define a new set or registers for your new
> instructions? Registers are modeled as fields in a structure, and both
> helpers and TCG implementations modify those fields while performing
> instruction emulation.
>
> In any case, you pass to the helper all information needed for the
> instruction in question to perform. These are usually ordinal numbers of
> involved register, derived from decoding the opcode. Alternatively, you
can
> pass pointers to the registers, rather than ordinal numbers. In turn, the
> main part of functionality is implemented. At the end of helper, you may
> want to update, let's say, a status register, if any (depending on your
> design).
>
> The declaration of helpers is a little contrived, and may still confuse
> you. But this is not crucial to you. I advise you just to copy a solution
> for a similar existing instruction.
>
> Yours,
> Aleksandar
>
>
>
> > Cheers,
> > Libo
> >
> >
> >
> >
> > ------------------ Original message ------------------
> > *From:* "Aleksandar Markovic";
> > *Sendtime:* Thursday, Aug 22, 2019 6:53 PM
> > *To:* "Libo Zhou";
> > *Cc:* "qemu-devel";
> > *Subject:* Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
> >
> > On Thu, Aug 22, 2019 at 12:24 PM 立 <zhlb29@foxmail.com> wrote:
> >
> > > Hi Aleksandar,
> > >
> > > Thank you very much for your patient explanation in the previous post.
> > And
> > > thank you for checking.
> > > Your and Peter's replies in the previous post certainly helped a lot.
I
> > am
> > > now looking at a git commit 7 years ago (
> > > bd277fa1966bc400f1b411f868f39125cda0c403), it was a Loongson
Multimedia
> > > Instruction implementation done my Richard Henderson.
> > >
> >
> > Cool, that commit is a very good staring point - it is definitely not
too
> > simple, and it is not too complex either. And you can discover several
> > different concepts in the process of exploring the change.
> >
> > Documentation on instruction set extension related to the commit (found
by
> > Google):
> > https://files.somniafabularum.com/loongson/docs/Loongson2FUserGuide.pdf
> >
> > Be persistent, take your time, study the details and handling of
individual
> > instructions, and, of course, let us know if you encounter some major
> > obstacles or thorny dilemmas.
> >
> > Yours,
> > Aleksandar
> >
> >
> > > I think what he did is exactly what I want to do now. I got a vague
view
> > > of the big picture, but I need more time to figure out the details. I
> > will
> > > certainly ask more questions about this later, but before that I need
to
> > > look at some other parts of the source code:) Again thank you for
> > checking!
> > >
> > > Cheers,
> > > Libo
> > >
> > >
> > > ------------------ Original message ------------------
> > > *From:* "Aleksandar Markovic";
> > > *Sendtime:* Thursday, Aug 22, 2019 4:23 PM
> > > *To:* "立";
> > > *Cc:* "qemu-devel";
> > > *Subject:* Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
> > >
> > > On Tue, Aug 20, 2019 at 12:12 PM 立 <zhlb29@foxmail.com> wrote:
> > >
> > > > I am working on a project that requires me to modify the ISA of the
> > MIPS
> > > > target.
> > >
> > >
> > > L.,
> > >
> > > How is it going?
> > >
> > > Aleksandar
> > >
> > >
> > >
> > > > I have been staring at the source code for about a week, but found
it
> > > > really difficult due to me being a young rookie and the sparse
> > comments.
> > > > Specifically, I need to extend MIPS, by adding some new instructions
> > and
> > > > new CPU registers to the current architecture, and that sounds
really
> > > easy.
> > > > I think the place for me to look at should be at the directory
> > > > ${qemu_root}/target/mips/. With a MIPS Instruction Set Manual
Release 6
> > > > handy, I have difficulty finding the source code where the ISA
resides.
> > > Is
> > > > it in op_helper.c? Or translate.c? Any guidance would be really
> > > > appreciated. Thank you very much in advance.
> > > >
> > > >
> > > > Cheers,
> > > > L.
> > >
> >

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[Aleksandar Markovic]

04.09.2019. 05.23, "Libo Zhou" <zhlb29@foxmail.com> је написао/ла:
>
> Hi Aleksandar,
>
> I have spent some time looking at your MXU ASE patch. It's super helpful.
I need to do exactly the same thing as you did.
>
> Now I just need a way to observe the memory and register file contents to
debug my instruction set simulator. I played with the "-d" switch to log a
bunch of information, but it seems that none of the items is of my
interest. The "-d cpu_reset" option displays all zeros in the GPR log.
>

It looks you need a custom logging tailored to your needs, based on
intercepting the instructions you added.

Aleksandar

> Please take your time, as I fully understand you need to work on Qemu
while answering all my questions. Again, thank you very much for your help!
>
> Cheers,
> Libo
>

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[Libo Zhou]

Do you know where in the source file I should look into to add my custom logging functionality?


Or, would you suggest using gdb to look at my target register and memory contents? The answer in this link below looks really promising. I'm gonna give it a try first.

https://stackoverflow.com/questions/39503997/how-to-run-a-single-line-of-assembly-then-see-r1-and-condition-flags



However, if I am able to customize log, it will be super convenient.



Cheers,

Libo



------------------ Original ------------------
From:  "Aleksandar Markovic";<aleksandar.m.mail@gmail.com>;
Send time: Thursday, Sep 5, 2019 6:54 PM
To: "Libo Zhou"<zhlb29@foxmail.com>; 
Cc: "qemu-devel"<qemu-devel@nongnu.org>; 
Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)



04.09.2019. 05.23, "Libo Zhou" <zhlb29@foxmail.com> ?е написао/ла:
>
> Hi Aleksandar,
>
> I have spent some time looking at your MXU ASE patch. It's super helpful.
I need to do exactly the same thing as you did.
>
> Now I just need a way to observe the memory and register file contents to
debug my instruction set simulator. I played with the "-d" switch to log a
bunch of information, but it seems that none of the items is of my
interest. The "-d cpu_reset" option displays all zeros in the GPR log.
>

It looks you need a custom logging tailored to your needs, based on
intercepting the instructions you added.

Aleksandar

> Please take your time, as I fully understand you need to work on Qemu
while answering all my questions. Again, thank you very much for your help!
>
> Cheers,
> Libo
>

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[Alex Bennée]

Libo Zhou <zhlb29@foxmail.com> writes:

> Do you know where in the source file I should look into to add my custom logging functionality?
>
>
> Or, would you suggest using gdb to look at my target register and memory contents? The answer in this link below looks really promising. I'm gonna give it a try first.
>
> https://stackoverflow.com/questions/39503997/how-to-run-a-single-line-of-assembly-then-see-r1-and-condition-flags

The gdbstub should allow you do full introspection and adding
additional registers is fairly easy, see FOO_gdb_[set|get]_reg helpers
in the appropriate target/FOO directories.

> However, if I am able to customize log, it will be super convenient.

So you want something above what -d cpu will show you?

>
>
>
> Cheers,
>
> Libo
>
>
>
> ------------------ Original ------------------
> From:  "Aleksandar Markovic";<aleksandar.m.mail@gmail.com>;
> Send time: Thursday, Sep 5, 2019 6:54 PM
> To: "Libo Zhou"<zhlb29@foxmail.com>;
> Cc: "qemu-devel"<qemu-devel@nongnu.org>;
> Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
>
>
>
> 04.09.2019. 05.23, "Libo Zhou" <zhlb29@foxmail.com> ?е написао/ла:
>>
>> Hi Aleksandar,
>>
>> I have spent some time looking at your MXU ASE patch. It's super helpful.
> I need to do exactly the same thing as you did.
>>
>> Now I just need a way to observe the memory and register file contents to
> debug my instruction set simulator. I played with the "-d" switch to log a
> bunch of information, but it seems that none of the items is of my
> interest. The "-d cpu_reset" option displays all zeros in the GPR log.
>>
>
> It looks you need a custom logging tailored to your needs, based on
> intercepting the instructions you added.
>
> Aleksandar
>
>> Please take your time, as I fully understand you need to work on Qemu
> while answering all my questions. Again, thank you very much for your help!
>>
>> Cheers,
>> Libo
>>


--
Alex Bennée

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[Alex Bennée]

Libo Zhou <zhlb29@foxmail.com> writes:

> Hi Alex,
>
>
> I just need to log the registers and memory after the program finishes
> its execution. Is it possible to add this functionality myself?

You'll need to set some sort of breakpoint on the last instruction so
gdb can inspect things before the program is unloaded. I think it's
possible to wire poweroff events to the gdbstub but I haven't looked
into that myself.

> As for the GDB option, can you tell me the specific steps to do that? I've tried it myself but I had no luck getting it running due to me being new to all this.
>

For linux-user:

  $QEMU -g 1234 $PRG

for system emulation

  $QEMU -s -S

and then on the gdb end:

  gdb $BIN -ex "target remote localhost:1234"

and then you can operate as you normally do with a gdb session. GDB has
two scripting interfaces. The command mode is basically a list of gdb
commands but might work for what you want. If you want to be a bit more
programatic you can use python. See the example in
tests/guest-debug/test-gdbstub.py

>
> Thanks,
> Libo
>
>
>
> ------------------ Original ------------------
> From:  "Alex Bennée";<alex.bennee@linaro.org>;
> Send time: Thursday, Sep 5, 2019 8:58 PM
> To: "qemu-devel"<qemu-devel@nongnu.org>;
> Cc: "Aleksandar Markovic"<aleksandar.m.mail@gmail.com>;
> Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
>
>
>
>
> Libo Zhou <zhlb29@foxmail.com> writes:
>
>> Do you know where in the source file I should look into to add my custom logging functionality?
>>
>>
>> Or, would you suggest using gdb to look at my target register and memory contents? The answer in this link below looks really promising. I'm gonna give it a try first.
>>
>> https://stackoverflow.com/questions/39503997/how-to-run-a-single-line-of-assembly-then-see-r1-and-condition-flags
>
> The gdbstub should allow you do full introspection and adding
> additional registers is fairly easy, see FOO_gdb_[set|get]_reg helpers
> in the appropriate target/FOO directories.
>
>> However, if I am able to customize log, it will be super convenient.
>
> So you want something above what -d cpu will show you?
>
>>
>>
>>
>> Cheers,
>>
>> Libo
>>
>>
>>
>> ------------------ Original ------------------
>> From:  "Aleksandar Markovic";<aleksandar.m.mail@gmail.com>;
>> Send time: Thursday, Sep 5, 2019 6:54 PM
>> To: "Libo Zhou"<zhlb29@foxmail.com>;
>> Cc: "qemu-devel"<qemu-devel@nongnu.org>;
>> Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
>>
>>
>>
>> 04.09.2019. 05.23, "Libo Zhou" <zhlb29@foxmail.com> ?е написао/ла:
>>>
>>> Hi Aleksandar,
>>>
>>> I have spent some time looking at your MXU ASE patch. It's super helpful.
>> I need to do exactly the same thing as you did.
>>>
>>> Now I just need a way to observe the memory and register file contents to
>> debug my instruction set simulator. I played with the "-d" switch to log a
>> bunch of information, but it seems that none of the items is of my
>> interest. The "-d cpu_reset" option displays all zeros in the GPR log.
>>>
>>
>> It looks you need a custom logging tailored to your needs, based on
>> intercepting the instructions you added.
>>
>> Aleksandar
>>
>>> Please take your time, as I fully understand you need to work on Qemu
>> while answering all my questions. Again, thank you very much for your help!
>>>
>>> Cheers,
>>> Libo
>>>


--
Alex Bennée

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[Alex Bennée]

Libo Zhou <zhlb29@foxmail.com> writes:

> Hi Alex,
>
>
> gdb says remote 'g' packet reply is too long, and then prints out a
> long string of zeros and some other digits sparsely.

Sounds like your gdb isn't multiarch aware. Debian/Ubuntu have multiarch
binutils which are aware of more than just the host architecture.

>
>
> I have tried a lot of combinations of flags but I just can't get it running properly. Do you know what is causing this error?
>
>
> Cheers,
>
> Libo
>
>
>
>
>
> ------------------ Original ------------------
> From:  "Alex Bennée";<alex.bennee@linaro.org>;
> Send time: Friday, Sep 6, 2019 5:19 PM
> To: "Libo Zhou"<zhlb29@foxmail.com>;
> Cc: "qemu-devel"<qemu-devel@nongnu.org>; "Aleksandar Markovic"<aleksandar.m.mail@gmail.com>;
> Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
>
>
>
>
> Libo Zhou <zhlb29@foxmail.com> writes:
>
>> Hi Alex,
>>
>>
>> I just need to log the registers and memory after the program finishes
>> its execution. Is it possible to add this functionality myself?
>
> You'll need to set some sort of breakpoint on the last instruction so
> gdb can inspect things before the program is unloaded. I think it's
> possible to wire poweroff events to the gdbstub but I haven't looked
> into that myself.
>
>> As for the GDB option, can you tell me the specific steps to do that? I've tried it myself but I had no luck getting it running due to me being new to all this.
>>
>
> For linux-user:
>
>   $QEMU -g 1234 $PRG
>
> for system emulation
>
>   $QEMU -s -S
>
> and then on the gdb end:
>
>   gdb $BIN -ex "target remote localhost:1234"
>
> and then you can operate as you normally do with a gdb session. GDB has
> two scripting interfaces. The command mode is basically a list of gdb
> commands but might work for what you want. If you want to be a bit more
> programatic you can use python. See the example in
> tests/guest-debug/test-gdbstub.py
>
>>
>> Thanks,
>> Libo
>>
>>
>>
>> ------------------ Original ------------------
>> From:  "Alex Bennée";<alex.bennee@linaro.org>;
>> Send time: Thursday, Sep 5, 2019 8:58 PM
>> To: "qemu-devel"<qemu-devel@nongnu.org>;
>> Cc: "Aleksandar Markovic"<aleksandar.m.mail@gmail.com>;
>> Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
>>
>>
>>
>>
>> Libo Zhou <zhlb29@foxmail.com> writes:
>>
>>> Do you know where in the source file I should look into to add my custom logging functionality?
>>>
>>>
>>> Or, would you suggest using gdb to look at my target register and memory contents? The answer in this link below looks really promising. I'm gonna give it a try first.
>>>
>>> https://stackoverflow.com/questions/39503997/how-to-run-a-single-line-of-assembly-then-see-r1-and-condition-flags
>>
>> The gdbstub should allow you do full introspection and adding
>> additional registers is fairly easy, see FOO_gdb_[set|get]_reg helpers
>> in the appropriate target/FOO directories.
>>
>>> However, if I am able to customize log, it will be super convenient.
>>
>> So you want something above what -d cpu will show you?
>>
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Libo
>>>
>>>
>>>
>>> ------------------ Original ------------------
>>> From:  "Aleksandar Markovic";<aleksandar.m.mail@gmail.com>;
>>> Send time: Thursday, Sep 5, 2019 6:54 PM
>>> To: "Libo Zhou"<zhlb29@foxmail.com>;
>>> Cc: "qemu-devel"<qemu-devel@nongnu.org>;
>>> Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
>>>
>>>
>>>
>>> 04.09.2019. 05.23, "Libo Zhou" <zhlb29@foxmail.com> ?е написао/ла:
>>>>
>>>> Hi Aleksandar,
>>>>
>>>> I have spent some time looking at your MXU ASE patch. It's super helpful.
>>> I need to do exactly the same thing as you did.
>>>>
>>>> Now I just need a way to observe the memory and register file contents to
>>> debug my instruction set simulator. I played with the "-d" switch to log a
>>> bunch of information, but it seems that none of the items is of my
>>> interest. The "-d cpu_reset" option displays all zeros in the GPR log.
>>>>
>>>
>>> It looks you need a custom logging tailored to your needs, based on
>>> intercepting the instructions you added.
>>>
>>> Aleksandar
>>>
>>>> Please take your time, as I fully understand you need to work on Qemu
>>> while answering all my questions. Again, thank you very much for your help!
>>>>
>>>> Cheers,
>>>> Libo
>>>>


--
Alex Bennée

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[Aleksandar Markovic]

10.09.2019. 11.57, "Libo Zhou" <zhlb29@foxmail.com> је написао/ла:
>
> Hi Alex,
>
> gdb says remote 'g' packet reply is too long, and then prints out a long
string of zeros and some other digits sparsely.
>
> I have tried a lot of combinations of flags but I just can't get it
running properly. Do you know what is causing this error?
>

This is a known bug, actually in gdb, but there is a workaround is to
rollback a commit made  around a year ago in QEMU, about 64-bit FPU Mips
registers. Or you can fix the buffer size in gdb.

Aleksandar

> Cheers,
> Libo
>
>
> ------------------ Original ------------------
> From:  "Alex Bennée";<alex.bennee@linaro.org>;
> Send time: Friday, Sep 6, 2019 5:19 PM
> To: "Libo Zhou"<zhlb29@foxmail.com>;
> Cc: "qemu-devel"<qemu-devel@nongnu.org>; "Aleksandar Markovic"<
aleksandar.m.mail@gmail.com>;
> Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
>
>
> Libo Zhou <zhlb29@foxmail.com> writes:
>
> > Hi Alex,
> >
> >
> > I just need to log the registers and memory after the program finishes
> > its execution. Is it possible to add this functionality myself?
>
> You'll need to set some sort of breakpoint on the last instruction so
> gdb can inspect things before the program is unloaded. I think it's
> possible to wire poweroff events to the gdbstub but I haven't looked
> into that myself.
>
> > As for the GDB option, can you tell me the specific steps to do that?
I've tried it myself but I had no luck getting it running due to me being
new to all this.
> >
>
> For linux-user:
>
>   $QEMU -g 1234 $PRG
>
> for system emulation
>
>   $QEMU -s -S
>
> and then on the gdb end:
>
>   gdb $BIN -ex "target remote localhost:1234"
>
> and then you can operate as you normally do with a gdb session. GDB has
> two scripting interfaces. The command mode is basically a list of gdb
> commands but might work for what you want. If you want to be a bit more
> programatic you can use python. See the example in
> tests/guest-debug/test-gdbstub.py
>
> >
> > Thanks,
> > Libo
> >
> >
> >
> > ------------------ Original ------------------
> > From:  "Alex Bennée";<alex.bennee@linaro.org>;
> > Send time: Thursday, Sep 5, 2019 8:58 PM
> > To: "qemu-devel"<qemu-devel@nongnu.org>;
> > Cc: "Aleksandar Markovic"<aleksandar.m.mail@gmail.com>;
> > Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
> >
> >
> >
> >
> > Libo Zhou <zhlb29@foxmail.com> writes:
> >
> >> Do you know where in the source file I should look into to add my
custom logging functionality?
> >>
> >>
> >> Or, would you suggest using gdb to look at my target register and
memory contents? The answer in this link below looks really promising. I'm
gonna give it a try first.
> >>
> >>
https://stackoverflow.com/questions/39503997/how-to-run-a-single-line-of-assembly-then-see-r1-and-condition-flags
> >
> > The gdbstub should allow you do full introspection and adding
> > additional registers is fairly easy, see FOO_gdb_[set|get]_reg helpers
> > in the appropriate target/FOO directories.
> >
> >> However, if I am able to customize log, it will be super convenient.
> >
> > So you want something above what -d cpu will show you?
> >
> >>
> >>
> >>
> >> Cheers,
> >>
> >> Libo
> >>
> >>
> >>
> >> ------------------ Original ------------------
> >> From:  "Aleksandar Markovic";<aleksandar.m.mail@gmail.com>;
> >> Send time: Thursday, Sep 5, 2019 6:54 PM
> >> To: "Libo Zhou"<zhlb29@foxmail.com>;
> >> Cc: "qemu-devel"<qemu-devel@nongnu.org>;
> >> Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
> >>
> >>
> >>
> >> 04.09.2019. 05.23, "Libo Zhou" <zhlb29@foxmail.com> ?е написао/ла:
> >>>
> >>> Hi Aleksandar,
> >>>
> >>> I have spent some time looking at your MXU ASE patch. It's super
helpful.
> >> I need to do exactly the same thing as you did.
> >>>
> >>> Now I just need a way to observe the memory and register file
contents to
> >> debug my instruction set simulator. I played with the "-d" switch to
log a
> >> bunch of information, but it seems that none of the items is of my
> >> interest. The "-d cpu_reset" option displays all zeros in the GPR log.
> >>>
> >>
> >> It looks you need a custom logging tailored to your needs, based on
> >> intercepting the instructions you added.
> >>
> >> Aleksandar
> >>
> >>> Please take your time, as I fully understand you need to work on Qemu
> >> while answering all my questions. Again, thank you very much for your
help!
> >>>
> >>> Cheers,
> >>> Libo
> >>>
>
>
> --
> Alex Bennée

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[Aleksandar Markovic]

10.09.2019. 19.26, aleksandar.m.mail@gmail.com је написао/ла:
>
>
> 10.09.2019. 11.57, "Libo Zhou" <zhlb29@foxmail.com> је написао/ла:
> >
> > Hi Alex,
> >
> > gdb says remote 'g' packet reply is too long, and then prints out a
long string of zeros and some other digits sparsely.
> >
> > I have tried a lot of combinations of flags but I just can't get it
running properly. Do you know what is causing this error?
> >
>
> This is a known bug, actually in gdb, but there is a workaround is to
rollback a commit made  around a year ago in QEMU, about 64-bit FPU Mips
registers.

More previsely, reverting
https://github.com/qemu/qemu/commit/8e0b373f8aa4b9feec7b44029455587e2e3d2b0f
would most likely rrmove your problem.

Aleksandar

> Or you can fix the buffer size in gdb.
>
> Aleksandar
>
> > Cheers,
> > Libo
> >
> >
> > ------------------ Original ------------------
> > From:  "Alex Bennée";<alex.bennee@linaro.org>;
> > Send time: Friday, Sep 6, 2019 5:19 PM
> > To: "Libo Zhou"<zhlb29@foxmail.com>;
> > Cc: "qemu-devel"<qemu-devel@nongnu.org>; "Aleksandar Markovic"<
aleksandar.m.mail@gmail.com>;
> > Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
> >
> >
> > Libo Zhou <zhlb29@foxmail.com> writes:
> >
> > > Hi Alex,
> > >
> > >
> > > I just need to log the registers and memory after the program finishes
> > > its execution. Is it possible to add this functionality myself?
> >
> > You'll need to set some sort of breakpoint on the last instruction so
> > gdb can inspect things before the program is unloaded. I think it's
> > possible to wire poweroff events to the gdbstub but I haven't looked
> > into that myself.
> >
> > > As for the GDB option, can you tell me the specific steps to do that?
I've tried it myself but I had no luck getting it running due to me being
new to all this.
> > >
> >
> > For linux-user:
> >
> >   $QEMU -g 1234 $PRG
> >
> > for system emulation
> >
> >   $QEMU -s -S
> >
> > and then on the gdb end:
> >
> >   gdb $BIN -ex "target remote localhost:1234"
> >
> > and then you can operate as you normally do with a gdb session. GDB has
> > two scripting interfaces. The command mode is basically a list of gdb
> > commands but might work for what you want. If you want to be a bit more
> > programatic you can use python. See the example in
> > tests/guest-debug/test-gdbstub.py
> >
> > >
> > > Thanks,
> > > Libo
> > >
> > >
> > >
> > > ------------------ Original ------------------
> > > From:  "Alex Bennée";<alex.bennee@linaro.org>;
> > > Send time: Thursday, Sep 5, 2019 8:58 PM
> > > To: "qemu-devel"<qemu-devel@nongnu.org>;
> > > Cc: "Aleksandar Markovic"<aleksandar.m.mail@gmail.com>;
> > > Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
> > >
> > >
> > >
> > >
> > > Libo Zhou <zhlb29@foxmail.com> writes:
> > >
> > >> Do you know where in the source file I should look into to add my
custom logging functionality?
> > >>
> > >>
> > >> Or, would you suggest using gdb to look at my target register and
memory contents? The answer in this link below looks really promising. I'm
gonna give it a try first.
> > >>
> > >>
https://stackoverflow.com/questions/39503997/how-to-run-a-single-line-of-assembly-then-see-r1-and-condition-flags
> > >
> > > The gdbstub should allow you do full introspection and adding
> > > additional registers is fairly easy, see FOO_gdb_[set|get]_reg helpers
> > > in the appropriate target/FOO directories.
> > >
> > >> However, if I am able to customize log, it will be super convenient.
> > >
> > > So you want something above what -d cpu will show you?
> > >
> > >>
> > >>
> > >>
> > >> Cheers,
> > >>
> > >> Libo
> > >>
> > >>
> > >>
> > >> ------------------ Original ------------------
> > >> From:  "Aleksandar Markovic";<aleksandar.m.mail@gmail.com>;
> > >> Send time: Thursday, Sep 5, 2019 6:54 PM
> > >> To: "Libo Zhou"<zhlb29@foxmail.com>;
> > >> Cc: "qemu-devel"<qemu-devel@nongnu.org>;
> > >> Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
> > >>
> > >>
> > >>
> > >> 04.09.2019. 05.23, "Libo Zhou" <zhlb29@foxmail.com> ?е написао/ла:
> > >>>
> > >>> Hi Aleksandar,
> > >>>
> > >>> I have spent some time looking at your MXU ASE patch. It's super
helpful.
> > >> I need to do exactly the same thing as you did.
> > >>>
> > >>> Now I just need a way to observe the memory and register file
contents to
> > >> debug my instruction set simulator. I played with the "-d" switch to
log a
> > >> bunch of information, but it seems that none of the items is of my
> > >> interest. The "-d cpu_reset" option displays all zeros in the GPR
log.
> > >>>
> > >>
> > >> It looks you need a custom logging tailored to your needs, based on
> > >> intercepting the instructions you added.
> > >>
> > >> Aleksandar
> > >>
> > >>> Please take your time, as I fully understand you need to work on
Qemu
> > >> while answering all my questions. Again, thank you very much for
your help!
> > >>>
> > >>> Cheers,
> > >>> Libo
> > >>>
> >
> >
> > --
> > Alex Bennée

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[Libo Zhou]

Reverting the commit solved my problem, although I don't know why it needed to be fixed to 64-bit back then. Finally I can now  single step a cross-compiled MIPS program on a QEMU Linux user binary and observe the register and memory contents.



------------------ Original ------------------
From:  "Aleksandar Markovic";<aleksandar.m.mail@gmail.com>;
Send time: Wednesday, Sep 11, 2019 1:50 AM
To: "Libo Zhou"<zhlb29@foxmail.com>; 
Cc: "Alex Bennée"<alex.bennee@linaro.org>; "qemu-devel"<qemu-devel@nongnu.org>; 
Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)



10.09.2019. 19.26, aleksandar.m.mail@gmail.com ?е написао/ла:
>
>
> 10.09.2019. 11.57, "Libo Zhou" <zhlb29@foxmail.com> ?е написао/ла:
> >
> > Hi Alex,
> >
> > gdb says remote 'g' packet reply is too long, and then prints out a
long string of zeros and some other digits sparsely.
> >
> > I have tried a lot of combinations of flags but I just can't get it
running properly. Do you know what is causing this error?
> >
>
> This is a known bug, actually in gdb, but there is a workaround is to
rollback a commit made  around a year ago in QEMU, about 64-bit FPU Mips
registers.

More previsely, reverting
https://github.com/qemu/qemu/commit/8e0b373f8aa4b9feec7b44029455587e2e3d2b0f
would most likely rrmove your problem.

Aleksandar

> Or you can fix the buffer size in gdb.
>
> Aleksandar
>
> > Cheers,
> > Libo
> >
> >
> > ------------------ Original ------------------
> > From:  "Alex Bennée";<alex.bennee@linaro.org>;
> > Send time: Friday, Sep 6, 2019 5:19 PM
> > To: "Libo Zhou"<zhlb29@foxmail.com>;
> > Cc: "qemu-devel"<qemu-devel@nongnu.org>; "Aleksandar Markovic"<
aleksandar.m.mail@gmail.com>;
> > Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
> >
> >
> > Libo Zhou <zhlb29@foxmail.com> writes:
> >
> > > Hi Alex,
> > >
> > >
> > > I just need to log the registers and memory after the program finishes
> > > its execution. Is it possible to add this functionality myself?
> >
> > You'll need to set some sort of breakpoint on the last instruction so
> > gdb can inspect things before the program is unloaded. I think it's
> > possible to wire poweroff events to the gdbstub but I haven't looked
> > into that myself.
> >
> > > As for the GDB option, can you tell me the specific steps to do that?
I've tried it myself but I had no luck getting it running due to me being
new to all this.
> > >
> >
> > For linux-user:
> >
> >   $QEMU -g 1234 $PRG
> >
> > for system emulation
> >
> >   $QEMU -s -S
> >
> > and then on the gdb end:
> >
> >   gdb $BIN -ex "target remote localhost:1234"
> >
> > and then you can operate as you normally do with a gdb session. GDB has
> > two scripting interfaces. The command mode is basically a list of gdb
> > commands but might work for what you want. If you want to be a bit more
> > programatic you can use python. See the example in
> > tests/guest-debug/test-gdbstub.py
> >
> > >
> > > Thanks,
> > > Libo
> > >
> > >
> > >
> > > ------------------ Original ------------------
> > > From:  "Alex Bennée";<alex.bennee@linaro.org>;
> > > Send time: Thursday, Sep 5, 2019 8:58 PM
> > > To: "qemu-devel"<qemu-devel@nongnu.org>;
> > > Cc: "Aleksandar Markovic"<aleksandar.m.mail@gmail.com>;
> > > Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
> > >
> > >
> > >
> > >
> > > Libo Zhou <zhlb29@foxmail.com> writes:
> > >
> > >> Do you know where in the source file I should look into to add my
custom logging functionality?
> > >>
> > >>
> > >> Or, would you suggest using gdb to look at my target register and
memory contents? The answer in this link below looks really promising. I'm
gonna give it a try first.
> > >>
> > >>
https://stackoverflow.com/questions/39503997/how-to-run-a-single-line-of-assembly-then-see-r1-and-condition-flags
> > >
> > > The gdbstub should allow you do full introspection and adding
> > > additional registers is fairly easy, see FOO_gdb_[set|get]_reg helpers
> > > in the appropriate target/FOO directories.
> > >
> > >> However, if I am able to customize log, it will be super convenient.
> > >
> > > So you want something above what -d cpu will show you?
> > >
> > >>
> > >>
> > >>
> > >> Cheers,
> > >>
> > >> Libo
> > >>
> > >>
> > >>
> > >> ------------------ Original ------------------
> > >> From:  "Aleksandar Markovic";<aleksandar.m.mail@gmail.com>;
> > >> Send time: Thursday, Sep 5, 2019 6:54 PM
> > >> To: "Libo Zhou"<zhlb29@foxmail.com>;
> > >> Cc: "qemu-devel"<qemu-devel@nongnu.org>;
> > >> Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
> > >>
> > >>
> > >>
> > >> 04.09.2019. 05.23, "Libo Zhou" <zhlb29@foxmail.com> ?е написао/ла:
> > >>>
> > >>> Hi Aleksandar,
> > >>>
> > >>> I have spent some time looking at your MXU ASE patch. It's super
helpful.
> > >> I need to do exactly the same thing as you did.
> > >>>
> > >>> Now I just need a way to observe the memory and register file
contents to
> > >> debug my instruction set simulator. I played with the "-d" switch to
log a
> > >> bunch of information, but it seems that none of the items is of my
> > >> interest. The "-d cpu_reset" option displays all zeros in the GPR
log.
> > >>>
> > >>
> > >> It looks you need a custom logging tailored to your needs, based on
> > >> intercepting the instructions you added.
> > >>
> > >> Aleksandar
> > >>
> > >>> Please take your time, as I fully understand you need to work on
Qemu
> > >> while answering all my questions. Again, thank you very much for
your help!
> > >>>
> > >>> Cheers,
> > >>> Libo
> > >>>
> >
> >
> > --
> > Alex Bennée

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[Aleksandar Markovic]

10.09.2019. 19.50, "Aleksandar Markovic" <aleksandar.m.mail@gmail.com> је
написао/ла:
>
>
> 10.09.2019. 19.26, aleksandar.m.mail@gmail.com је написао/ла:
> >
> >
> > 10.09.2019. 11.57, "Libo Zhou" <zhlb29@foxmail.com> је написао/ла:
> > >
> > > Hi Alex,
> > >
> > > gdb says remote 'g' packet reply is too long, and then prints out a
long string of zeros and some other digits sparsely.
> > >
> > > I have tried a lot of combinations of flags but I just can't get it
running properly. Do you know what is causing this error?
> > >
> >
> > This is a known bug, actually in gdb, but there is a workaround is to
rollback a commit made  around a year ago in QEMU, about 64-bit FPU Mips
registers.
>
> More previsely, reverting
https://github.com/qemu/qemu/commit/8e0b373f8aa4b9feec7b44029455587e2e3d2b0f
would most likely rrmove your problem.
>
> Aleksandar
>

I am going to submit reverting of this commit to the list, since it created
problems for multiple users.

Aleksandar

> > Or you can fix the buffer size in gdb.
> >
> > Aleksandar
> >
> > > Cheers,
> > > Libo
> > >
> > >
> > > ------------------ Original ------------------
> > > From:  "Alex Bennée";<alex.bennee@linaro.org>;
> > > Send time: Friday, Sep 6, 2019 5:19 PM
> > > To: "Libo Zhou"<zhlb29@foxmail.com>;
> > > Cc: "qemu-devel"<qemu-devel@nongnu.org>; "Aleksandar Markovic"<
aleksandar.m.mail@gmail.com>;
> > > Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
> > >
> > >
> > > Libo Zhou <zhlb29@foxmail.com> writes:
> > >
> > > > Hi Alex,
> > > >
> > > >
> > > > I just need to log the registers and memory after the program
finishes
> > > > its execution. Is it possible to add this functionality myself?
> > >
> > > You'll need to set some sort of breakpoint on the last instruction so
> > > gdb can inspect things before the program is unloaded. I think it's
> > > possible to wire poweroff events to the gdbstub but I haven't looked
> > > into that myself.
> > >
> > > > As for the GDB option, can you tell me the specific steps to do
that? I've tried it myself but I had no luck getting it running due to me
being new to all this.
> > > >
> > >
> > > For linux-user:
> > >
> > >   $QEMU -g 1234 $PRG
> > >
> > > for system emulation
> > >
> > >   $QEMU -s -S
> > >
> > > and then on the gdb end:
> > >
> > >   gdb $BIN -ex "target remote localhost:1234"
> > >
> > > and then you can operate as you normally do with a gdb session. GDB
has
> > > two scripting interfaces. The command mode is basically a list of gdb
> > > commands but might work for what you want. If you want to be a bit
more
> > > programatic you can use python. See the example in
> > > tests/guest-debug/test-gdbstub.py
> > >
> > > >
> > > > Thanks,
> > > > Libo
> > > >
> > > >
> > > >
> > > > ------------------ Original ------------------
> > > > From:  "Alex Bennée";<alex.bennee@linaro.org>;
> > > > Send time: Thursday, Sep 5, 2019 8:58 PM
> > > > To: "qemu-devel"<qemu-devel@nongnu.org>;
> > > > Cc: "Aleksandar Markovic"<aleksandar.m.mail@gmail.com>;
> > > > Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
> > > >
> > > >
> > > >
> > > >
> > > > Libo Zhou <zhlb29@foxmail.com> writes:
> > > >
> > > >> Do you know where in the source file I should look into to add my
custom logging functionality?
> > > >>
> > > >>
> > > >> Or, would you suggest using gdb to look at my target register and
memory contents? The answer in this link below looks really promising. I'm
gonna give it a try first.
> > > >>
> > > >>
https://stackoverflow.com/questions/39503997/how-to-run-a-single-line-of-assembly-then-see-r1-and-condition-flags
> > > >
> > > > The gdbstub should allow you do full introspection and adding
> > > > additional registers is fairly easy, see FOO_gdb_[set|get]_reg
helpers
> > > > in the appropriate target/FOO directories.
> > > >
> > > >> However, if I am able to customize log, it will be super
convenient.
> > > >
> > > > So you want something above what -d cpu will show you?
> > > >
> > > >>
> > > >>
> > > >>
> > > >> Cheers,
> > > >>
> > > >> Libo
> > > >>
> > > >>
> > > >>
> > > >> ------------------ Original ------------------
> > > >> From:  "Aleksandar Markovic";<aleksandar.m.mail@gmail.com>;
> > > >> Send time: Thursday, Sep 5, 2019 6:54 PM
> > > >> To: "Libo Zhou"<zhlb29@foxmail.com>;
> > > >> Cc: "qemu-devel"<qemu-devel@nongnu.org>;
> > > >> Subject:  Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)
> > > >>
> > > >>
> > > >>
> > > >> 04.09.2019. 05.23, "Libo Zhou" <zhlb29@foxmail.com> ?е написао/ла:
> > > >>>
> > > >>> Hi Aleksandar,
> > > >>>
> > > >>> I have spent some time looking at your MXU ASE patch. It's super
helpful.
> > > >> I need to do exactly the same thing as you did.
> > > >>>
> > > >>> Now I just need a way to observe the memory and register file
contents to
> > > >> debug my instruction set simulator. I played with the "-d" switch
to log a
> > > >> bunch of information, but it seems that none of the items is of my
> > > >> interest. The "-d cpu_reset" option displays all zeros in the GPR
log.
> > > >>>
> > > >>
> > > >> It looks you need a custom logging tailored to your needs, based on
> > > >> intercepting the instructions you added.
> > > >>
> > > >> Aleksandar
> > > >>
> > > >>> Please take your time, as I fully understand you need to work on
Qemu
> > > >> while answering all my questions. Again, thank you very much for
your help!
> > > >>>
> > > >>> Cheers,
> > > >>> Libo
> > > >>>
> > >
> > >
> > > --
> > > Alex Bennée

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[Libo Zhou]

Alex Bennée <alex.bennee@linaro.org> writes:


> The gdbstub should allow you do full introspection and adding
> additional registers is fairly easy, see mips_cpu_gdb_read_register function
> in  target/mips/gdbstub.c.



Hi Alex and Aleksandar,


Now I can connect gdb to qemu successfully. And I can use this command to show all the register contents in a gdb session.


(gdb) layout regs


However, I will need to add some more registers to the CPU. Does adding new registers in gdbstub.c also show the new registers in the TUI?
I doubt it because when I modified the regnames[] in translate.c, the registers' names didn't change in gdb.



Cheers,
Libo



> Alex Bennée

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[Alex Bennée]

Libo Zhou <zhlb29@foxmail.com> writes:

> Alex Bennée <alex.bennee@linaro.org> writes:
>
>
>> The gdbstub should allow you do full introspection and adding
>> additional registers is fairly easy, see mips_cpu_gdb_read_register function
>> in  target/mips/gdbstub.c.
>
>
>
> Hi Alex and Aleksandar,
>
>
> Now I can connect gdb to qemu successfully. And I can use this command
> to show all the register contents in a gdb session.

You will need to update gdb-xml/$ARCH.xml and the appropriate
arch_read/write register functions in gdbstub.

Alternatively look at commits:

  commit 200bf5b7ffea635079cc05fdfb363372b9544ce7
  Author: Abdallah Bouassida <abdallah.bouassida@lauterbach.com>
  commit 9c513e786d85cc58b8ba56a482566f759e0835b6
  Author: Abdallah Bouassida <abdallah.bouassida@lauterbach.com>
  commit 1f16378718fa87d63f70d0797f4546a88d8e3dd7
  Author: Abdallah Bouassida <abdallah.bouassida@lauterbach.com>

Where Abdallah added a dynamic xml generation to expose all the ARM
system registers to gdbstub. The details may be different for the MIPS
backend but from the gdbstub point of view its the same. Provide a
system description in xml and the arch specific helpers to get and set
the values.

>
>
> (gdb) layout regs
>
>
> However, I will need to add some more registers to the CPU. Does adding new registers in gdbstub.c also show the new registers in the TUI?
> I doubt it because when I modified the regnames[] in translate.c, the registers' names didn't change in gdb.
>
>
>
> Cheers,
> Libo
>
>
>
>> Alex Bennée


--
Alex Bennée

Re: [Qemu-devel] QEMU as ISS (Instruction Set Simulator)

[Libo Zhou]

Alex Bennée writes:

> You will need to update gdb-xml/$ARCH.xml and the appropriate
arch_read/write register functions in gdbstub.



For some mysterious reason my previous emails didn't go to the list successfully. Let me try sending this one without including any code or link.



The MIPS target doesn't have mips*.xml, so I tried implementing it myself. As per the "Standard Target Features" requirement by GDB, I created mips-cpu.xml, mips-cp0.xml, mips-fpu.xml, and finally included them all in a wrapper mips.xml. Essentially I followed this commit: b8158192fadb3e346372456c25cbbc4be584a85c. (Yes it failed because <feature> is nested in <feature>, so I nest <feature> in <target>.)


Unfortunately, it doesn't work. GDB just doesn't recognize my change. It still displays the default reg names (zero, at, v0, v1, a0, a1, etc.), but I want my r0, r1, ... r31.


So, I went to the i386 target, whose gdbstub is working properly, and tweaked with its xml to see if changing xml reg names reflects in GDB session. However, when I changed "rax" to "zax", GDB gave me a 'g' packet error. I am really stuck at this point.


I really want to post my git diff below, but let's see if my mail can go to the list this time. Sorry for the inconvenience.



Cheers,

Libo Zhou


P.S. The dynamic xml generation option is too difficult for me for now. I will save it as an alternative in the future.