[Lldb-commits] [PATCH] D146965: [lldb] Add support for MSP430 in LLDB.

Tue Apr 4 09:11:05 PDT 2023

DavidSpickett added a comment.

> It is completely bare metal, but the address space is only 16-bit, so would the entire 64 KB of memory count as a core dump?

It's more "world" than "core" but yeah why not. Probably won't need all 64k though, see below...

> I can make a test that checks if fallback information even exists and registers have correct data and size, for example.

Yes that would be great. Plus it documents our expectations (or lack of) from this third party debug stub.

> What else would you recommend to test for?

Backtrace is the obvious thing, assuming you have implemented any of that yet. What you could do is dump the stack from a real device and use the previously mentioned fake GDB remote to replay it to lldb.

Other things:

- Stepping
- Breakpoints, hardware and software. Also, do the breakpoints report an address after the stop or before.

If the feature mostly relies on the existing msp430 stub being correct, there's not much point testing it. For anything where lldb has to make some msp430 specific decision, see if you can mock up a gdb remote to test it.

================
Comment at: lldb/source/Plugins/Platform/Linux/PlatformLinux.cpp:127
          llvm::Triple::hexagon, llvm::Triple::mips, llvm::Triple::mips64el,
-         llvm::Triple::mipsel, llvm::Triple::systemz},
+         llvm::Triple::mipsel, llvm::Triple::msp430, llvm::Triple::systemz},
         llvm::Triple::Linux);
----------------
If this is bare metal why do we have changes to Linux code here? Or is this the default platform used when connecting to the msp430 debug stub.

That said, I'm not sure we A: support Hexagon or B: it runs linux either :)

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146965/new/

https://reviews.llvm.org/D146965