Hi Marc,
Em seg, 2 de jan de 2023 11:47, Marc Nieper-Wißkirchen <marc.nieper+gnu@gmail.com> escreveu:
>
> For purposes of dynamically calling code, I need the following layout
> of the assembled code:
>
> 0x00: 16-byte header
> 0x10: entry point #1
> 0x20: entry point #2
>
> I want to use the new align/skip instructions for this. My code
> generator currently looks like this:
>
> align (16)
> header:
> skip (16)
> entry1:
> jump label1
> align (16)
> entry2:
> ...
> label1:
> jump entry2 ; or some other code
>
> However, with setup, GNU lightning often "optimizes" the block order
> so that entry1 is no longer at the correct offset. How can I reliably
> prohibit this? Putting skip (1) after the second align (16) seems to
> help in my experiments.
The skip might be working due possibly confusing the optimizer in
some way that might change in the future. It would be good to have
an example to fully understand the condition.
Your code should be already ensuring that the entry is already 16
bytes aligned.
There is no block reordering, but the pattern:
entry1:
jmp label1
....
entry2:
...
label1:
jmp entry2
will be usually changed to:
entry1:
jmp entry2
...
entry2:
due to simple/safe jump threading optimization.
Arguably this could be also "the" bug breaking your logic. If the
"..." after "jmp entry2" is either "note", "name" or align it might
remove the "jmp entry2". I mean arguably because the original idea
for "align" was just to align labels, and filled with nops.
Please experiment removing the:
case jit_code_align:
from lib/lightning.c:_redundant_jump()
I will push a patch for the above case as it clearly could break
the usage you describe.
You can also use jit_indirect() to prevent a label from being optimized
or removed, or move the address to a register and use jit_jmpr() as a
way to prevent any optimization. But the logic you are describing must
be supported.
> Thanks,
>
> Marc
Thanks,
Paulo