Re: [Qemu-devel] Question about gen_jmp_tb
Hi Richard, thanks for your help. Which instruction, then, I should add my gen_helper to in order for it to be called at the end of each basic block, as I've previously stated? Is there a way I can generically have this change apply to every target? Jack On 05/30/2014 06:25 PM, Richard Henderson wrote: On 05/30/2014 01:56 AM, Jack Biggs wrote: Hi all, I'm trying to add some arbitrary code to the end of each translation block, and I wanted to confirm my suspicion that each translation block ends in a jmp instruction, and that each translation block ends (or jumps to another TB) with the call to gen_jmp_tb. My guest is i386, but if this is architecture-specific I'd like to know more about per-target semantics. No, not every tb ends with gen_jmp_tb. Indeed, only those for which we have an immediate address end that way. Plenty of tb's end with indirect branches, or for a variety of other reasons. Certainly gen_jmp_tb is specific to the i386 translator. r~
Re: [Qemu-devel] Question about gen_jmp_tb
Jack Biggs writes: Hi Richard, thanks for your help. Which instruction, then, I should add my gen_helper to in order for it to be called at the end of each basic block, as I've previously stated? Is there a way I can generically have this change apply to every target? Jack On 05/30/2014 06:25 PM, Richard Henderson wrote: On 05/30/2014 01:56 AM, Jack Biggs wrote: Hi all, I'm trying to add some arbitrary code to the end of each translation block, and I wanted to confirm my suspicion that each translation block ends in a jmp When you say arbitrary code what do you mean? Are you wanting to put backend specific code there or a common post-amble of tcg ops? Can you give a bit more detail about your use case? instruction, and that each translation block ends (or jumps to another TB) with the call to gen_jmp_tb. My guest is i386, but if this is architecture-specific I'd like to know more about per-target semantics. No, not every tb ends with gen_jmp_tb. Indeed, only those for which we have an immediate address end that way. Plenty of tb's end with indirect branches, or for a variety of other reasons. Certainly gen_jmp_tb is specific to the i386 translator. r~ -- Alex Bennée
Re: [Qemu-devel] Question about gen_jmp_tb
When you say arbitrary code what do you mean? Are you wanting to put backend specific code there or a common post-amble of tcg ops? Can you give a bit more detail about your use case? I'm trying to add a clock-synchronization library so that I can have two (or more) instances of QEMU run in a synchronized (deterministic) fashion. The arbitrary code is more or less a function call (i.e., callq) instruction to a function that uses shared semaphores to block execution. Jack
Re: [Qemu-devel] Question about gen_jmp_tb
On 2 June 2014 11:15, Jack Biggs john.bi...@epfl.ch wrote: When you say arbitrary code what do you mean? Are you wanting to put backend specific code there or a common post-amble of tcg ops? Can you give a bit more detail about your use case? I'm trying to add a clock-synchronization library so that I can have two (or more) instances of QEMU run in a synchronized (deterministic) fashion. The arbitrary code is more or less a function call (i.e., callq) instruction to a function that uses shared semaphores to block execution. Bear in mind that we can also exit a TB via taking an unexpected exception [usually a load/store which faults], in which case we'll effectively longjump out of the middle of it. If you can rearrange your design to only require your hooks to be called at the *start* of a TB, not the end, that is much easier -- the existing icount machinery does that already. thanks -- PMM
Re: [Qemu-devel] Question about gen_jmp_tb
Hi Peter, This is not a problem for now, the main reason we wanted to have this at the end is to potentially trace load / stores in the future. How would you recommend integrating this into icount? Just wanting to make sure I don't run into anything unexpected. Regards, Jack On 06/02/2014 12:47 PM, Peter Maydell wrote: If you can rearrange your design to only require your hooks to be called at the *start* of a TB, not the end, that is much easier -- the existing icount machinery does that already. thanks -- PMM
Re: [Qemu-devel] Question about gen_jmp_tb
On 2 June 2014 11:53, Jack Biggs john.bi...@epfl.ch wrote: This is not a problem for now, the main reason we wanted to have this at the end is to potentially trace load / stores in the future. How would you recommend integrating this into icount? Just wanting to make sure I don't run into anything unexpected. The icount hooks are in gen-icount.h. thanks -- PMM
[Qemu-devel] Question about gen_jmp_tb
Hi all, I'm trying to add some arbitrary code to the end of each translation block, and I wanted to confirm my suspicion that each translation block ends in a jmp instruction, and that each translation block ends (or jumps to another TB) with the call to gen_jmp_tb. My guest is i386, but if this is architecture-specific I'd like to know more about per-target semantics. Thanks a lot, Jack
Re: [Qemu-devel] Question about gen_jmp_tb
On 05/30/2014 01:56 AM, Jack Biggs wrote: Hi all, I'm trying to add some arbitrary code to the end of each translation block, and I wanted to confirm my suspicion that each translation block ends in a jmp instruction, and that each translation block ends (or jumps to another TB) with the call to gen_jmp_tb. My guest is i386, but if this is architecture-specific I'd like to know more about per-target semantics. No, not every tb ends with gen_jmp_tb. Indeed, only those for which we have an immediate address end that way. Plenty of tb's end with indirect branches, or for a variety of other reasons. Certainly gen_jmp_tb is specific to the i386 translator. r~
