lightning
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]