Mismatching ABI between ArduinoRuntime and the rest of the targets

[AeroStun]

Direct cause of this CI failure

[AeroStun]

Update: within a single stacktrace, two frames accessing the same address obtain different results

[AeroStun]

Only possible explanation is that the DLL somehow ends up with a different virtual memory space, but this is supposedly impossible since previous demos have demonstrated that user-code actions can be observed by the main thread

[AeroStun]

Better yet, with Clang: from a single stack frame, depending on how the pointer to the object is accessed, different results are obtained (see that from the lambda I get a pin_modes of size 1, and from the global, which points at the same address, I get a pin_modes of size 0)

[AeroStun]

Update: tried setting an x86 hardware watchpoint using LLDB on board_info->pins_caps._M_impl._M_start (yes I use libstdc++), and the watchpoint does not fire

[AeroStun]

We have reached a whole other level

[AeroStun]

It only gets better...

For those who don't read hex, basically the memory shows a vector containing one element, but somehow the evaluation (and the runtime code) believes that it reads three consecutive NULLs in memory (which is obviously not the case since otherwise the whole highlighted memory would be full of only 00s)

[AeroStun]

Have I mentioned that debuggers are useless?

[platisd]

This seems like the definition of an undefined behavior. Is there something that's not initialized perhaps?

[AeroStun]

Undefined behavior does not affect operator sizeof since its operands are unevaluated (only the type of the expression is used) I suspect that LLDB is trying to JIT some of its evaluations with different build options

EDIT: suspicion confirmed: LLDB does seem to be doing some broken dark magic resulting in two completely different evaluation contexts, where one is based on the debug symbols, and the other on some JIT-compiled snippets using the wrong compiler options

[AeroStun]

Next assumption: broken ABI

[AeroStun]

CONFIRMED: broken ABI

• SMCE and its tests compile in non-debug mode, hence they use std::__cxx1998::vector
• ArduinoRuntime compiles in debug mode, hence it uses the 56 bytes long (what the hell do they even use that extra space for? Gotta go read their debug impl now) std::__debug::vector

[AeroStun]

Morale of the story: too much debugging kills the debugging And second morale is that debuggers can't be trusted since they don't tell the user how they got the results from expression evaluation; only Valgrind stands trustworthy