[debugserver] align received mach exception data before accessing it as array of uint64_t's, fix UB sanitizer failure

[jasonmolenda]

Summary

The mach exception data received in debugserver is not aligned to a doubleword boundary. Most of these were fixed in 2017 by Vedant ([MachException] Avoid alignment UB, NFC) but there was a codepath when debugserver logging is enabled where we would still access the mach exception data without aligning it first. This has been causing failures on the sanitizer greendragon bot for the last few days from Jim's change in https://reviews.llvm.org/D157556 where he is enabling LOG_EXCEPTIONS debugserver logging unconditionally (this should prob be in a self.TraceOn() conditional, or maybe not even be in the test - it looks like a debug print he forgot to remove) in the new test_shadow_listener test.

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-sanitized/

Simplest fix, and it's only done when LOG_EXCEPTIONS is enabled, is to align the data one-off for the logging.

I would have handed this to Jim to fix, but by the time I understood what the actual failure was, it was nothing to fix it.

[jasonmolenda]

I'm going to land this one sans-approval to fix the CI bot. but I still think

self.runCmd("settings set target.process.extra-startup-command QSetLogging:bitmask=LOG_PROCESS|LOG_EXCEPTIONS|LOG_RNB_PACKETS|LOG_STEP;")

shouldn't be in a test case, even though it helpfully found this ubsan issue.

lldb/tools/debugserver/source/MacOSX/MachException.cpp

 }
 
 extern "C" kern_return_t
 catch_mach_exception_raise(mach_port_t exc_port, mach_port_t thread_port,
                            mach_port_t task_port, exception_type_t exc_type,
                            mach_exception_data_t exc_data,
                            mach_msg_type_number_t exc_data_count) {
   if (DNBLogCheckLogBit(LOG_EXCEPTIONS)) {
+    std::vector<uint64_t> exc_datas;
+    uint64_t tmp;
+    for (unsigned i = 0; i < exc_data_count; ++i) {
+      // Perform an unaligned copy.
+      memcpy(&tmp, &exc_data[i], sizeof(uint64_t));
+      exc_datas.push_back(tmp);
+    }
     DNBLogThreaded("::%s ( exc_port = 0x%4.4x, thd_port = 0x%4.4x, tsk_port = "
                    "0x%4.4x, exc_type = %d ( %s ), exc_data[%d] = { 0x%llx, "
                    "0x%llx })",
                    __FUNCTION__, exc_port, thread_port, task_port, exc_type,
                    MachException::Name(exc_type), exc_data_count,
-                   (uint64_t)(exc_data_count > 0 ? exc_data[0] : 0xBADDBADD),
-                   (uint64_t)(exc_data_count > 1 ? exc_data[1] : 0xBADDBADD));
+                   (uint64_t)(exc_data_count > 0 ? exc_datas[0] : 0xBADDBADD),
+                   (uint64_t)(exc_data_count > 1 ? exc_datas[1] : 0xBADDBADD));
   }
   g_message->exc_type = 0;
   g_message->exc_data.clear();
 
   if (task_port == g_message->task_port) {
     g_message->task_port = task_port;
     g_message->thread_port = thread_port;
     g_message->exc_type = exc_type;