On Tue, Jan 25, 2011 at 10:04:39AM +0100, Stefano Bonifazi wrote:
> Again wow!! Is that really possible? Some sort of callback triggered at
> every instruction execution?
> > Yes, this mechanism works. I have written a code to count different
> > kinds of instructions.
> Great! that opens a lot
On 01/25/2011 10:05 AM, Edgar E. Iglesias wrote:
On Tue, Jan 25, 2011 at 10:04:39AM +0100, Stefano Bonifazi wrote:
Again wow!! Is that really possible? Some sort of callback triggered at
every instruction execution?
Yes, this mechanism works. I have written a code to count different
kinds of in
Again wow!! Is that really possible? Some sort of callback triggered at
every instruction execution?
Yes, this mechanism works. I have written a code to count different
kinds of instructions.
Great! that opens a lot of possibilities!.
It exists in file qemu/target-i386/translate.c
Ops right! I
That said, QEMU's currently working fairly well on this front too, so
studying either should work pretty well...
Mr Richard Henderson's patch on elfload.c says I was right.. at least
the version I am working on (qemu-0.13.0) had some bugs and weaknesses
though it worked smoothly for most case
You should see this pdf
(www.ecs.syr.edu/faculty/yin/Teaching/TC2010/Proj4.pdf). It talks
about tracing the instructions.
--
Dushyant
Wow thank you! It sounds incredibly interesting!!
What we really need is to insert a function call into the
translated code, so when each instruction is exec
On 01/24/2011 03:16 PM, Stefano Bonifazi wrote:
> Hi! Thanks for replying me!
>> The thing is, the kernel currently _does_ work, so studying the relevant
>> kernel code (and possibly the dynamic loader code) is one way to learn
>> how it currently works.
> Sorry what kernel? Qemu's? Linux's?
QEMU
Hi! Thanks for replying me!
The thing is, the kernel currently _does_ work, so studying the relevant
kernel code (and possibly the dynamic loader code) is one way to learn
how it currently works.
Sorry what kernel? Qemu's? Linux's?
On 01/24/2011 07:02 PM, Dushyant Bansal wrote:
On Monday 24 January 2011 08:26 PM, Stefano Bonifazi wrote:
On 01/24/2011 03:32 PM, Peter Maydell wrote:
Being a JIT doesn't prohibit counting target instructions executed.
It just means that counting them generally requires generating
code to do
On 01/24/2011 04:17 AM, Stefano Bonifazi wrote:
> I read your post, and yup you also noticed the weird of load_bias.. and
> wondered how it can work on x86..
> But I think your work was on qemu-system.. I am working on qemu-user..
My post wasn't on qemu-anything, it was while I was trying to debu
On Monday 24 January 2011 08:26 PM, Stefano Bonifazi wrote:
On 01/24/2011 03:32 PM, Peter Maydell wrote:
Being a JIT doesn't prohibit counting target instructions executed.
It just means that counting them generally requires generating
code to do the counting at runtime, so it's a more complica
Stefano Bonifazi writes:
> On 01/24/2011 03:32 PM, Peter Maydell wrote:
>>
>> Being a JIT doesn't prohibit counting target instructions executed.
>> It just means that counting them generally requires generating
>> code to do the counting at runtime, so it's a more complicated
>> change to make th
On 01/24/2011 03:32 PM, Peter Maydell wrote:
Being a JIT doesn't prohibit counting target instructions executed.
It just means that counting them generally requires generating
code to do the counting at runtime, so it's a more complicated
change to make than it would be in a non-JIT emulator.
W
2011/1/23 Rob Landley :
> Keep in mind I'm a bit rusty and not an expert, but I'll give a stab at
> answering:
...here's a couple of clarifications:
>> 2. "how can I check the number of target cpu cycles or target
>> instructions executed inside qemu-user (i.e. qemu-ppc)?
> You can't, because QE
On 01/24/2011 12:40 AM, Rob Landley wrote:
On 01/23/2011 04:25 PM, Stefano Bonifazi wrote:
I am trying to shift in memory the target executable .. now the code is
"supposed" to be loaded by the elfloader at the exact start address set
at link time ..
Ah, elf loading. That's a whole 'nother bag
On 01/23/2011 04:25 PM, Stefano Bonifazi wrote:
> I am trying to shift in memory the target executable .. now the code is
> "supposed" to be loaded by the elfloader at the exact start address set
> at link time ..
Ah, elf loading. That's a whole 'nother bag of worms.
Oddly enough, I was deling w
On 01/23/2011 10:50 PM, Rob Landley wrote:
On 01/16/2011 10:01 AM, Raphaël Lefèvre wrote:
On Sun, Jan 16, 2011 at 11:21 PM, Stefano Bonifazi
wrote:
2. "how can I check the number of target cpu cycles or target
instructions executed inside qemu-user (i.e. qemu-ppc)?
Is there any variable I can
On 01/16/2011 10:01 AM, Raphaël Lefèvre wrote:
> On Sun, Jan 16, 2011 at 11:21 PM, Stefano Bonifazi
> wrote:
> 2. "how can I check the number of target cpu cycles or target
> instructions executed inside qemu-user (i.e. qemu-ppc)?
> Is there any variable I can inspect for such informations?" at De
Stefano Bonifazi writes:
> Hi!
> In case you are interested in helping me, I'll give you a big piece of news
> I've just got (even my teacher is not informed yet! :) )
I still don't understand what is your high-level objective...
Lluis
--
"And it's much the same thing with knowledge, for wh
2011/1/17 Stefano Bonifazi :
> Hi!
> In case you are interested in helping me, I'll give you a big piece of news
> I've just got (even my teacher is not informed yet! :) )
> I've just managed to make more than one instance of qemu-user run at the
> same time linking the target code with a specifie
Hi!
In case you are interested in helping me, I'll give you a big piece of
news I've just got (even my teacher is not informed yet! :) )
I've just managed to make more than one instance of qemu-user run at the
same time linking the target code with a specified address for the code
section (-Tt
2011/1/16 Stefano Bonifazi :
> I need to make the different instances of qemu-user exchange data ..
> obviously keeping all of them in the same address space would be the easiest
> way (unless I have to change all qemu code ;) )
The problem is that you're trying to break a fundamental
assumption m
2011/1/17 Stefano Bonifazi :
>
> Hi!
> Thank you very much for Your concern!
> Honestly I had lost hope in any help, I even contacted directly some
> developers in this mailing list without luck!
I guess many good developers in mailing list are still try their best
to solve your problems, such as
Thank you very much for Your fast reply!
On 01/16/2011 07:29 PM, Peter Maydell wrote:
Linux doesn't seem to have dlmopen
http://www.unix.com/man-page/All/3c/dlmopen/
#define __USE_GNU
#include
lib_handle1 = dlmopen(LM_ID_NEWLM,"./libqemu-ppc.so", RTLD_NOW);
I am developing that on a clean
2011/1/16 Stefano Bonifazi :
> My workaround to this problem was compiling qemu-ppc as a dynamic library
> and load it at runtime.. I also managed to load multiple copies of it (with
> dlmopen each at a different address space) ..in fact I need to run more than
> one qemu-ppc at the same time
This
Sorry for my belated on this discussion, after I searched for the
topics you posted, it seems two main problems are unsolved? (Am I
right?? I'm not sure...)
1. "I edited QEMU user, more exactly qemu-ppc launching the main function
(inside main.c) from another c function I created, passing it th
On Sun, Jan 16, 2011 at 11:21 PM, Stefano Bonifazi
wrote:
>
> Thank you very much!
> I've already solved this problem.. Right now I am fighting with the
> possibility of changing qemu-user code for making it run several binaries in
> succession .. But it seems to remember the first translated co
On 01/16/2011 03:46 PM, Raphael Lefevre wrote:
On Wed, Dec 15, 2010 at 4:17 AM, Stefano Bonifazi
wrote:
> On 12/11/2010 03:44 PM, Blue Swirl wrote:
>
> Hi!
> Thank you very much! Knowing exactly where I should check, in a so big
> project helped me very much!!
> Anyway after having spen
On Wed, Dec 15, 2010 at 4:17 AM, Stefano Bonifazi
wrote:
> On 12/11/2010 03:44 PM, Blue Swirl wrote:
>
> Hi!
> Thank you very much! Knowing exactly where I should check, in a so big
> project helped me very much!!
> Anyway after having spent more than 2 days on that code I still can't
> u
On 12/11/2010 03:44 PM, Blue Swirl wrote:
On Sat, Dec 11, 2010 at 2:32 PM, Stefano Bonifazi
wrote:
Where does the execution of host binary take place in the previous list of
events? Between point 5) and 6) ?
After 6) ? In what QEMU source code file/function does the final execution of
host
On Sat, Dec 11, 2010 at 2:32 PM, Stefano Bonifazi
wrote:
> -Original Message-
> From: Blue Swirl [mailto:blauwir...@gmail.com]
> Sent: sabato 11 dicembre 2010 14:12
> To: Stefano Bonifazi
> Cc: qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] TCG flow vs dyngen
>
-Original Message-
From: Blue Swirl [mailto:blauwir...@gmail.com]
Sent: sabato 11 dicembre 2010 14:12
To: Stefano Bonifazi
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] TCG flow vs dyngen
>There's a large buffer for generated code, allocated in exec.c. This is filled
&g
On Sat, Dec 11, 2010 at 12:29 PM, Stefano Bonifazi
wrote:
> Thank you very very much! I'd take months for understanding everything
> myself from the source code! :)
>
> On 12/11/2010 12:02 PM, Blue Swirl wrote:
>>
>> On Fri, Dec 10, 2010 at 9:26 PM, Stefano Bonifazi
>> wrote:
>>>
>>> [..]
>>>
>>
Thank you very very much! I'd take months for understanding everything
myself from the source code! :)
On 12/11/2010 12:02 PM, Blue Swirl wrote:
On Fri, Dec 10, 2010 at 9:26 PM, Stefano Bonifazi
wrote:
[..]
- So, I think that the technical documentation is now obsolete, isn't it?
At least
On Fri, Dec 10, 2010 at 9:26 PM, Stefano Bonifazi
wrote:
> Hi all!
> From the technical documentation
> (http://www.usenix.org/publications/library/proceedings/usenix05/tech/freenix/bellard.html)
> I read:
>
> The first step is to split each target CPU instruction into fewer simpler
> instruction
34 matches
Mail list logo
