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
