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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
