[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some issues on 32-bit x86
From: |
Paulo César Pereira de Andrade |
Subject: |
Re: Some issues on 32-bit x86 |
Date: |
Thu, 3 Aug 2023 10:39:02 -0300 |
Em ter., 1 de ago. de 2023 às 18:38, Paul Cercueil
<paul@crapouillou.net> escreveu:
[snip]
> Calling jit_get_code() returns a size of 147. I therefore create a
> buffer of 147 bytes and set it with jit_set_code() along with the size
> == 147.
>
> With that setup, jit_emit() will fail and return NULL.
>
> If I create a buffer twice as big and call jit_set_code() with size ==
> (147*2), jit_emit() will succeed, and a subsequent call to
> jit_get_code() will return a size of just 17 bytes.
>
> The actual code generated is the following:
>
> -----
> # rec_special_JR:/home/paul/dev/lightrec/emitter.c:80
> 0x20002754 mov 0x7c(%edi),%esi
> 0x20002757 mov %esi,0x210(%edi)
> 0x2000275d sub $0x4,%eax
> 0x20002760 jmp 0x20000ca4
> -----
This is strange, probably it wil be required more context. It should have
calculated:
63 + 6 + 6 +6 + 5 = 86
63 is because it requires a remaining JIT_INSTR_MAX before
emitting an instruction, and all codes, but jmpi have a guessed 6
bytes requirement.
Please check if you can add a breakpoint and 'call _jit_print(_jit)' so
we can see what is really being generated.
> So it's surprising that it can't work with a buffer of 147 bytes when
> it only really need 17 bytes.
>
> Thoughts?
You should be prepared to use page sized buffers for safety and
better portability.
> Cheers,
> -Paul