Faszinierende Assembly zum Vergleichen von std :: optional von primitiven Typen

Valgrind hat einen Aufruhr aufgefangen Bedingter Sprung oder Bewegung hängt von nicht initialisierten Werten ab in einem meiner Unit-Tests.

Als ich die Baugruppe inspizierte, stellte ich fest, dass der folgende Code:

bool operator==(MyType const& left, MyType const& right) {
    // ... some code ...
    if (left.getA() != right.getA()) { return false; }
    // ... some code ...
    return true;
}

Dabei hat MyType::getA() const -> std::optional<std::uint8_t> die folgende Assembly generiert:

   0x00000000004d9588 <+108>:   xor    eax,eax
   0x00000000004d958a <+110>:   cmp    BYTE PTR [r14+0x1d],0x0
   0x00000000004d958f <+115>:   je     0x4d9597 <... function... +123>
x  0x00000000004d9591 <+117>:   mov    r15b,BYTE PTR [r14+0x1c]
x  0x00000000004d9595 <+121>:   mov    al,0x1

   0x00000000004d9597 <+123>:   xor    edx,edx
   0x00000000004d9599 <+125>:   cmp    BYTE PTR [r13+0x1d],0x0
   0x00000000004d959e <+130>:   je     0x4d95ae <... function... +146>
x  0x00000000004d95a0 <+132>:   mov    dil,BYTE PTR [r13+0x1c]
x  0x00000000004d95a4 <+136>:   mov    dl,0x1
x  0x00000000004d95a6 <+138>:   mov    BYTE PTR [rsp+0x97],dil

   0x00000000004d95ae <+146>:   cmp    al,dl
   0x00000000004d95b0 <+148>:   jne    0x4da547 <... function... +4139>

   0x00000000004d95b6 <+154>:   cmp    r15b,BYTE PTR [rsp+0x97]
   0x00000000004d95be <+162>:   je     0x4d95c8 <... function... +172>

    => Jump on uninitialized

   0x00000000004d95c0 <+164>:   test   al,al
   0x00000000004d95c2 <+166>:   jne    0x4da547 <... function... +4139>

Wo ich mit x markiert habe, die Anweisungen, die nicht ausgeführt werden (übersprungen), wenn das optionale NICHT gesetzt ist.

Das Mitglied A befindet sich hier am Versatz 0x1c in MyType. Beim Überprüfen des Layouts von std::optional sehen wir Folgendes:

• +0x1d entspricht bool _M_engaged,
• +0x1c entspricht std::uint8_t _M_payloadinnerhalb einer anonymen Union).

Der Code von Interesse für std::optional ist:

constexpr explicit operator bool() const noexcept
{ return this->_M_is_engaged(); }

// Comparisons between optional values.
template<typename _Tp, typename _Up>
constexpr auto operator==(const optional<_Tp>& __lhs, const optional<_Up>& __rhs) -> __optional_relop_t<decltype(declval<_Tp>() == declval<_Up>())>
{
    return static_cast<bool>(__lhs) == static_cast<bool>(__rhs)
         && (!__lhs || *__lhs == *__rhs);
}

Hier können wir sehen, dass gcc den Code ziemlich grundlegend verändert hat; wenn ich es richtig verstehe, ergibt sich in C:

char rsp[0x148]; // simulate the stack

/* comparisons of prior data members */

/*
0x00000000004d9588 <+108>:   xor    eax,eax
0x00000000004d958a <+110>:   cmp    BYTE PTR [r14+0x1d],0x0
0x00000000004d958f <+115>:   je     0x4d9597 <... function... +123>
0x00000000004d9591 <+117>:   mov    r15b,BYTE PTR [r14+0x1c]
0x00000000004d9595 <+121>:   mov    al,0x1
*/

int eax = 0;
if (__lhs._M_engaged == 0) { goto b123; }
bool r15b = __lhs._M_payload;
eax = 1;

b123:
/*
0x00000000004d9597 <+123>:   xor    edx,edx
0x00000000004d9599 <+125>:   cmp    BYTE PTR [r13+0x1d],0x0
0x00000000004d959e <+130>:   je     0x4d95ae <... function... +146>
0x00000000004d95a0 <+132>:   mov    dil,BYTE PTR [r13+0x1c]
0x00000000004d95a4 <+136>:   mov    dl,0x1
0x00000000004d95a6 <+138>:   mov    BYTE PTR [rsp+0x97],dil
*/

int edx = 0;
if (__rhs._M_engaged == 0) { goto b146; }
rdi = __rhs._M_payload;
edx = 1;
rsp[0x97] = rdi;

b146:
/*
0x00000000004d95ae <+146>:   cmp    al,dl
0x00000000004d95b0 <+148>:   jne    0x4da547 <... function... +4139>
*/

if (eax != edx) { goto end; } // return false

/*
0x00000000004d95b6 <+154>:   cmp    r15b,BYTE PTR [rsp+0x97]
0x00000000004d95be <+162>:   je     0x4d95c8 <... function... +172>
*/

//  Flagged by valgrind
if (r15b == rsp[097]) { goto b172; } // next data member

/*
0x00000000004d95c0 <+164>:   test   al,al
0x00000000004d95c2 <+166>:   jne    0x4da547 <... function... +4139>
*/

if (eax == 1) { goto end; } // return false

b172:

/* comparison of following data members */

end:
    return false;

Welches ist gleichbedeutend mit:

//  Note how the operands of || are inversed.
return static_cast<bool>(__lhs) == static_cast<bool>(__rhs)
         && (*__lhs == *__rhs || !__lhs);

I _ (denkedass die Assembly korrekt ist, wenn auch seltsam. Soweit ich sehen kann, beeinflusst das Ergebnis des Vergleichs zwischen nicht initialisierten Werten das Ergebnis der Funktion nicht wirklich (und anders als C oder C++, I Erwarten Sie, dass der Vergleich von Junk in der x86-Assembly NICHT UB ist.

1. Wenn eine Option nullopt ist und die andere festgelegt ist, springt der bedingte Sprung bei +148 zu endreturn false), OK.
2. Wenn beide Optionen eingestellt sind, werden beim Vergleich die initialisierten Werte angezeigt. OK.

Der einzige interessierende Fall ist also, wenn beide Optionen nullopt sind:

• wenn die Werte gleich sind, kommt der Code zu dem Schluss, dass die Optionen gleich sind, was wahr ist, da beide nullopt sind.
• andernfalls kommt der Code zu dem Schluss, dass die Optionen gleich sind, wenn __lhs._M_engaged false ist, was true ist.

In beiden Fällen kommt der Code daher zu dem Schluss, dass beide Optionen gleich sind, wenn beide nullopt sind. CQFD.

Dies ist das erste Mal, dass gcc scheinbar "harmlose" nicht initialisierte Lesevorgänge generiert. Daher habe ich ein paar Fragen:

1. _ (Sind nicht initialisierte Lesevorgänge in Assembly (x84_64) in Ordnung?
2. Ist dies das Syndrom einer fehlgeschlagenen Optimierung (Umkehrung von ||), die unter nicht-harmlosen Umständen ausgelöst werden könnte?

Im Moment neige ich dazu, die wenigen Funktionen mit optimize(1) zu kommentieren, um Optimierungen zu vermeiden. Glücklicherweise sind die identifizierten Funktionen nicht leistungskritisch.

Umgebung:

• compiler: gcc 7.3
• compile flags: -std=c++17 -g -Wall -Werror -O3 -flto (+ passende Includes)
• link Flags: -O3 -flto (+ entsprechende Bibliotheken)

Hinweis: Kann mit -O2 anstelle von -O3 erscheinen, jedoch niemals ohne -flto.

Wissenswertes

Im vollständigen Code erscheint dieses Muster 32 Mal in der oben beschriebenen Funktion für verschiedene Nutzdaten: std::uint8_t, std::uint32_t, std::uint64_t und sogar einen struct { std::int64_t; std::int8_t; }.

Es erscheint nur in einigen großen operator== Vergleichstypen mit ~ 40 Datenelementen, nicht in kleineren. Und es erscheint nicht für den std::optional<std::string_view>, auch nicht in den spezifischen Funktionen (die für den Vergleich std::char_traits aufrufen).

Schließlich lässt das Isolieren der fraglichen Funktion in einer eigenen Binärdatei das "Problem" wütend werden. Das mythische MCVE erweist sich als schwer fassbar.