Page MenuHomePhabricator

[LLDB] Add support for AVR breakpoints
Needs ReviewPublic

Authored by aykevl on Fri, Feb 7, 1:59 PM.



I believe the actual opcode does not matter because the AVR architecture is a Harvard architecture that does not support writing to program memory. Therefore, debuggers and emulators provide hardware breakpoints. But for some reason, this opcode must be defined or else LLDB will crash with an assertion error.

I would like to add a test case for this, but I'm not quite sure how to do that. It appears that to trigger the crash (fixed by this patch), there needs to be a gdb-remote.

Diff Detail

Event Timeline

aykevl created this revision.Fri, Feb 7, 1:59 PM
Herald added a project: Restricted Project. · View Herald TranscriptFri, Feb 7, 1:59 PM
labath added a comment.Fri, Feb 7, 2:52 PM

We have infrastructure to "mock" a gdb-remote server (see packages/Python/lldbsuite/test/functionalities/gdb_remote_client/) to test lldb's interaction with it.

For a simple patch like this, I don't think a test is really required (especially as they are not the easiest tests to write), but OTOH, you are going to need this sooner or later, so now may be a good time to try it out.

jingham added a subscriber: jingham.Fri, Feb 7, 2:58 PM

Might also be good to fix the crash. If you don't support software breakpoints, you shouldn't get asked what your breakpoint opcode is.

The whole flow here is pretty nonsensical -- the only reason we ask for the opcode is to get its size so we can put it into the Z0 packet -- however this is only needed for targets like arm, which have mutiple ISAs/opcodes, and we've already gotten complaints about sending that unconditionally.

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.