On 09/18/2015 03:44 PM, Peter Maydell wrote:
Well, if we're going to add a margin we need to add the worst-case margin.
I guess the worst case is that deltas of the insn_data words between each insn
are useless, and we need full 64-bit values to represent them -- 9 bytes for
the sleb128. The deltas between sequential guest pc values will always be
small -- 1 byte. The deltas between the host insns implementing guest pc
values could be moderate (think move-multiple type insns performing 16 guest
loads); two byte sleb128 gives us 16k range.
So worst case is (1 + 9*TARGET_INSN_START_EXTRA_WORDS + 2) * TCG_MAX_INSNS.
Which is 10k for mips; 6k for sparc and some others; 1.5k for alpha and all
others that have no extra words.
However it occurred to me that the reason we use a margin for the codegen
is that we don't want to do a check for overrun every time we write
code to the buffer. For the datatable it seems more feasible to do
buffer length checks as we write the data. If we run out of space then
we just throw away the TB we generated (along with everything else in
the buffer) and start again.
Yeah, I guess we could do that.
Would the idea with the guard page be to catch the segfault and use
that as our trigger to clear the codegen buffer and start again?
Well, my idea was simply to use a guard page instead of asserts. But seeing a
write to the known guard page and causing code gen to restart after flushing
the buffer is an awesome idea.
It does have implications for a theoretic host that can't set page permissions.
But I'm not sure we support such a host even now, so discarding all of the
non-mmap, non-win32 alternatives for allocating the code_gen_buffer doesn't
strike me as the worst of ideas.
r~
