https://github.com/DavidSpickett commented:
This whole thing is a bit strange to begin with. We have these "external" breakpoints managed by the debug stub, but we have to tell it what size they should be because the client does all the parsing of the program file. Which makes sense for keeping the server light, but it is a bit odd to be in this half way house where we can offload some of the work to the stub, but not all of it. Anyway, add it to the pile of gdb remote protocol gripes. It is what it is :) I've done a brief review. We'll need a test case to prove we do the substitution or don't, when the feature is present or not. That'll involve a mock gdb stub, which we have (`MockGDBServerResponder`) assuming you can mock enough stuff to get the BreakpointSites working. That might prove tricky so I can help you with that, I've spent way too much time staring at mock server tests. The solution of a new feature feels like a thing we shouldn't have to do but the aforementioned pile of gripes is full of examples like this because the protocol is not as rigorous as I'd like. So let me check what GDB does and how it does it, but I think I'll be in favour of this solution even so. This new feature should be documented in https://lldb.llvm.org/resources/lldbgdbremote.html#qsupported. We don't currently list all our specific features, and we should, but you don't have to do that. You can replace: > In the example above, three lldb extensions are shown: With something like: > lldb extensions include, but are not limited to: And add your new one there. We can deal with listing the others some other time in some other PR. Finally, I don't know how much freedom you have to contribute to OpenOCD but making it replace the breakpoint instructions would be good too. I didn't see any requests for it on their issue tracker but I expect that's because lldb -> OpenOCD is a fraction of their user base. At least open an issue if you can, and point to the issues here in llvm. Then future users might find it and realise they need to update their LLDB if it hasn't been fixed in OpenOCD yet (and I doubt it ever would be because GDB "works fine" :) ). https://github.com/llvm/llvm-project/pull/201176 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
