dylanmckay added a comment. > However, if we look at this locally, if the AVR architecture has a trap > opcode (maybe to implement __builtin_debugbreak() -- I am assuming that's > what 0x98 0x95 is), then I don't see a problem with this function returning > it.
Chiming in from an AVR perspective, the AVR does have a trap opcode (`BREAK`) and this is encoded by 0x9895 > The BREAK instruction is used by the On-chip Debug system, and is normally > not used in the application > software. When the BREAK instruction is executed, the AVR CPU is set in the > Stopped Mode. This gives the > On-chip Debugger access to internal resources. > > If any Lock bits are set, or either the JTAGEN or OCDEN Fuses are > unprogrammed, the CPU will treat the > BREAK instruction as a NOP and will not enter the Stopped mode. > > This instruction is not available in all devices. Refer to the device > specific instruction set summary. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D74255/new/ https://reviews.llvm.org/D74255 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits