From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LZoXO-0003Sj-7s for qemu-devel@nongnu.org; Wed, 18 Feb 2009 10:40:38 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LZoXM-0003Rn-AQ for qemu-devel@nongnu.org; Wed, 18 Feb 2009 10:40:37 -0500 Received: from [199.232.76.173] (port=51541 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LZoXL-0003Rc-SV for qemu-devel@nongnu.org; Wed, 18 Feb 2009 10:40:35 -0500 Received: from rv-out-0708.google.com ([209.85.198.249]:47401) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LZoXL-00065H-Db for qemu-devel@nongnu.org; Wed, 18 Feb 2009 10:40:35 -0500 Received: by rv-out-0708.google.com with SMTP id f25so2628334rvb.22 for ; Wed, 18 Feb 2009 07:40:34 -0800 (PST) Message-ID: <499C2BEF.6010107@gmail.com> Date: Wed, 18 Feb 2009 10:40:31 -0500 From: Andrea Pellegrini MIME-Version: 1.0 Subject: Re: [Qemu-devel] Monitor Memory Accesses References: <499C03A9.6040003@gmail.com> <761ea48b0902180500wbe676d4x3895d37df10e495b@mail.gmail.com> <499C0A81.8090106@gmail.com> <761ea48b0902180526q1be52725x748c7c14b5d907de@mail.gmail.com> In-Reply-To: <761ea48b0902180526q1be52725x748c7c14b5d907de@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Thanks Laurent, I slightly modified the code from Vince and it worked great for my purpose (at least to monitor the PC). Just a quick question: In the file linux-user/mmap.c, which is the difference between the two following lines? Does the first one provide the virtual address while the second one is already translated in the real address? p = mmap(g2h(mmap_start), host_len, prot, flags | MAP_FIXED, fd, host_offset); p = mmap(real_start ? g2h(real_start) : NULL, host_len, prot, flags, fd, host_offset); I'm just starting to work on tracking the load/store. :-) ~Andrea Laurent Desnogues wrote: > On Wed, Feb 18, 2009 at 2:17 PM, Andrea Pellegrini > wrote: > >> Thanks for the quick reply! >> >> I obtain the instruction addresses through the function >> static TranslationBlock *tb_find_slow(target_ulong pc, >> target_ulong cs_base, >> uint64_t flags) >> >> ...... >> // Andrea, let's check the pc >> printf("PC: 0x%x\n", pc); >> .... >> >> in cpu_exec.c. So far it worked but maybe there is a better way to do it. >> > > No, it doesn't work. Try to track the PC of a loop and you'll see > what I mean. > > You should start by learning what is run-time code generation ;) > > >> Where can I find more informations about the "helper"? >> I'm just starting working with Qemu so I'm still not 100% sure about what is >> going on. :-P >> > > The documentation is the source. It's not easy to enter, but once > you've understood the basic inner-workings, doing what you're > after should not be very difficult. > > >> I searched in target-i386/translate.c for >> tcg_gen_qemu_ld >> or >> tcg_gen_qemu_lst >> and nothing pops up. Am I looking at the right thing? >> > > I talked about tcg_gen_qemu_ld*. > > Just to make it clear, I am talking of svn version of qemu. If you're > using 0.9.1 then it's a completely different story, and I invite you to > take a look at Vince Weaver's work: > > http://www.csl.cornell.edu/~vince/projects/qemusim/ > http://www.csl.cornell.edu/~vince/projects/qemu-trace/ > > > Laurent > > > >