программа падает нормально, но не с Valgrind

Question

Я пытаюсь отлаживать часть программы сборки (x86 64-bit), и в соответствии с информацией gdb, он выходит из строя при использовании следующей инструкции:

xorpd 0x1770(%rip),%xmm12  # 0x40337c <S_0x403230> 

Тем не менее, кажется, мне, что память 0x40337c совершенно нормальна:

(gdb) x /10x 0x40337c 
0x40337c <S_0x403230>: 0x00000000  0x80000000  0x00000000  0x00000000 
0x40338c <S_0x403240>: 0xf149f2ca  0x00000000  0x746e7973  0x203a7861 
0x40339c <S_0x403248+8>:  0x206d626c  0x6d69743c 

Другое проводное является то, что этот кусок коды падает каждый раз, когда я запускаю его в командной строке, а также внутри gdb. Однако, когда я отлаживаю его в valgrind, он не сбой!

☁ src [master] ⚡ valgrind ./a.out 20 reference.dat 0 1 100_100_130_cf_a.of 
==18329== Memcheck, a memory error detector 
==18329== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. 
==18329== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info 
==18329== Command: ./a.out 20 reference.dat 0 1 100_100_130_cf_a.of 
==18329== 
MAIN_printInfo: 
    grid size  : 100 x 100 x 130 = 1.30 * 10^6 Cells 
    nTimeSteps  : 20 
    result file : reference.dat 
    action   : nothing 
    simulation type: channel flow 
    obstacle file : 100_100_130_cf_a.of 

LBM_showGridStatistics: 
    nObstacleCells: 498440 nAccelCells:  0 nFluidCells: 801560 
    minRho: 1.0000 maxRho: 1.0000 mass: 1.300000e+06 
minU: 0.000000e+00 maxU: 0.000000e+00 

LBM_showGridStatistics: 
    nObstacleCells: 498440 nAccelCells:  0 nFluidCells: 801560 
    minRho: 1.0000 maxRho: 1.0431 mass: 1.300963e+06 
    minU: 0.000000e+00 maxU: 1.272361e-02 

==18329== 
==18329== HEAP SUMMARY: 
    ==18329==  in use at exit: 0 bytes in 0 blocks 
==18329== total heap usage: 4 allocs, 4 frees, 428,801,136 bytes allocated 
==18329== 
==18329== All heap blocks were freed -- no leaks are possible 
==18329== 
==18329== For counts of detected and suppressed errors, rerun with: -v 
==18329== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) 

Я загрузил двоичный код на here для справки, если вы заинтересованы. Программа сборки фактически создается двоичным перезаписывателем, и я использовал, чтобы иметь возможность создавать бесплатный код. Поэтому я считаю, что это не может быть проблемой для разыменования указателей с отладкой, должно быть что-то очень легко исправить. Однако я действительно не знаю, где идет не так, и кажется, что это нормально в отладке gdb (x/10x 0x40337)

Так вот мой вопрос,

1. учитывая отладочная информация (x/10x 0x40337c), где может пойти не так?

2. Почему двоичный код не сбой в valgrind?

Answer 1

Valgrind runs your code on a simulated x86 CPU. По-видимому, он не моделирует проверку выравнивания.

---

128-разрядные и большие операнды памяти для инструкций SSE всегда должны быть выровнены естественным образом. (например, к границе 16B для нагрузки 16B, такой как эта). Исключением является MOVUPS (_mm_loadu_ps) (и MOVUPD/MOVDQU).

0x40337c не соответствует 16B, только 4B. (Так что довольно странно, что вы используете его с XORPD, так как я ожидал бы, по крайней мере, 8B-выравнивания для double).

Инструкции AVX - это обратное: по умолчанию не требуется выравнивание, но VMOVAPS требует выравнивания.