From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KLfkh-0004KA-Hf for qemu-devel@nongnu.org; Wed, 23 Jul 2008 10:55:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KLfkf-0004J4-QH for qemu-devel@nongnu.org; Wed, 23 Jul 2008 10:55:39 -0400 Received: from [199.232.76.173] (port=55150 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KLfkf-0004Iw-Im for qemu-devel@nongnu.org; Wed, 23 Jul 2008 10:55:37 -0400 Received: from rv-out-0708.google.com ([209.85.198.250]:29345) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KLfkf-0006O5-3G for qemu-devel@nongnu.org; Wed, 23 Jul 2008 10:55:37 -0400 Received: by rv-out-0708.google.com with SMTP id f25so1761096rvb.22 for ; Wed, 23 Jul 2008 07:55:33 -0700 (PDT) Message-ID: <761ea48b0807230755k25f8a580k69597eedb6c73c15@mail.gmail.com> Date: Wed, 23 Jul 2008 16:55:33 +0200 From: "Laurent Desnogues" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [Qemu-devel] [RFD] Translation block instrumentation and multiple TCG code buffers 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 Hello, some people are interested in instrumenting translated blocks for various reasons. For instance, Paul Brook added instruction counting; another use includes instruction profiling. Both these examples require the full basic block to have been translated, while the counters updates should be at the beginning of the translated block. To achieve that, Paul did what he calls a "horrid hack": generate a tcg subi which is patched with the correct count once the BB has been translated. When there is a single instruction to patch one can live with that hack, but when one wants more, something cleaner is definitely needed. One possible solution would be to have two tcg code buffers. Instrumentation tcg ops would go into the second buffer; that second buffer would generate code before generating code for the translated block. I think the cleanest way to do that would be to move gen_opc_ptr and gen_opparam_ptr to the tcg context (BTW this is already hinted in tcg.c) and have a mechanism to change between the first and second buffer when needed. (Note I am not sure using multiple tcg contexts is really the way to go at the moment given the way some of the code assumes a single context exists [for instance the profiler].) One could be more ambitious and have more than two buffers (for instance, Paul's counter has to generate code that goes after the BB has been translated), but that could come later. What do people think? Cheers, Laurent