- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
// https://github.com/dotnet/coreclr/blob/a9f3fc16483eecfc47fb79c362811d870be02249/src/vm/i386/cgenx86.cpp#L1613
PCODE DynamicHelpers::CreateHelperWithTwoArgs(LoaderAllocator * pAllocator, TADDR arg, TADDR arg2, PCODE target)
{
#ifdef UNIX_X86_ABI
BEGIN_DYNAMIC_HELPER_EMIT(23);
#else
BEGIN_DYNAMIC_HELPER_EMIT(17);
#endif
#ifdef UNIX_X86_ABI
// sub esp, 4
*p++ = 0x83;
*p++ = 0xec;
*p++ = 0x4;
#else
// pop eax
*p++ = 0x58;
#endif
// push arg
*p++ = 0x68;
*(INT32 *)p = arg;
p += 4;
// push arg2
*p++ = 0x68;
*(INT32 *)p = arg2;
p += 4;
#ifdef UNIX_X86_ABI
// mov eax, target
*p++ = 0xB8;
*(INT32 *)p = target;
p += 4;
#else
// push eax
*p++ = 0x50;
#endif
*p++ = X86_INSTR_JMP_REL32; // jmp rel32
#ifdef UNIX_X86_ABI
*(INT32 *)p = rel32UsingJumpStub((INT32 *)p, (PCODE)DynamicHelperArgsStub);
#else
*(INT32 *)p = rel32UsingJumpStub((INT32 *)p, target);
#endif
p += 4;
END_DYNAMIC_HELPER_EMIT();
}
Функция из дотнеткора, которая нахерачивает опкодов куда-то.
j123123 28.10.2020 22:40 # 0
Единственный вариант что тут они не обосрались - это если INT32 тип это хуйня с каким-то специальным атрибутом, что через него можно срать по невыровненным адресам. В ином случае это UB
bormand 28.10.2020 22:41 # 0
j123123 28.10.2020 22:44 # 0
https://stackoverflow.com/questions/51126257/
bormand 28.10.2020 22:50 # 0
3.9 Types
5. The alignment of a complete object type is an implementation-defined integer value representing a number of bytes.
Т.е. стандарт не утверждает, что uint32_t обязан быть выровнен на 4 байта, это реализация решает.
j123123 28.10.2020 22:54 # +1
guest8 28.10.2020 22:55 # −999
guest6 02.11.2020 22:38 # 0
j123123 28.10.2020 23:02 # +2
https://pzemtsov.github.io/2016/11/06/bug-story-alignment-on-x86.html
Suddenly, our x86 behaves just like RISC: it crashes when a pointer to uint32_t is not aligned by 4.
Какой багор )))
rotoeb 28.10.2020 23:08 # +1
guest8 28.10.2020 23:12 # −999
j123123 28.10.2020 23:17 # 0
guest8 28.10.2020 23:19 # −999
j123123 29.10.2020 14:35 # 0
Вот тут упоминается мотороловский процессор 68000 который был CISC и при этом там была хуйня с сигфолтами от невыровненных доступов к памяти, но в чуть более новых процессорах такой хуйни уже не было:
> The original 68000 was a processor with two-byte granularity and lacked the circuitry to cope with unaligned addresses. When presented with such an address, the processor would throw an exception. The original Mac OS didn’t take very kindly to this exception, and would usually demand the user restart the machine. Ouch.
> Later processors in the 680×0 series, such as the 68020, lifted this restriction and performed the necessary work for you. This explains why some old software that works on the 68020 crashes on the 68000. It also explains why, way back when, some old Mac coders initialized pointers with odd addresses. On the original Mac, if the pointer was accessed without being reassigned to a valid address, the Mac would immediately drop into the debugger. Often they could then examine the calling chain stack and figure out where the mistake was.
Motorola 05.09.2021 21:52 # 0
guest8 28.10.2020 23:31 # −999
Arbatan_Pokrovan 28.10.2020 23:43 # 0
Saehrimnir 29.10.2020 12:04 # 0
В SSE есть две инструкции для одного и того же, но одна из них падает на невыровненных данных, как в RISC, а другая работает с любым указателем?
j123123 28.10.2020 23:26 # 0
Такого же рода хуйню я находил, когда ковырялся в исходниках GHC. Правда там были не опкоды x86-64, а байткодная поебень для GHCi
Saehrimnir 29.10.2020 11:59 # 0
j123123 29.10.2020 13:58 # +1
Можно сделать особую функцию с memcpy
хотя такую функцию можно и по другому написать, например
или так
bormand 29.10.2020 14:45 # 0