To support dumping the reproducer's GDB remote packets, we need the
(de)serialization logic to live in Utility rather than the GDB remote plugin.
This patch renames StreamGDBRemote to GDBRemote and moves the relevant packet
code there. Its uses in the GDBRemoteCommunicationHistory and the
GDBRemoteCommunicationReplayServer are updated as well.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
It seems weird to me to have the GDBRemotePacket class live in the repro namespace. There's nothing particularly Reproducer specific about it, and it clearly gets used outside the reproducer as well. Wouldn't it make more sense to have this in Utils?
Yep, I agree, and I considered alternatives but couldn't find a better solution. It's seems too specific for a utility class in itself and doesn't belong in Core or Target either. It really should be part of the GDB plugin, but then we can't access it without layering violations from Command...
There's already Utils/StreamGDBRemote.cpp... It might be natural to stick the class in there?
*Maybe* this is fine for now, but I also don't like moving the gdb-remote reproducer stuff out of the gdb plugin. If you want an inspection command to access those (which sounds like a useful thing btw), then the right way to handle that would be to have some sort of an abstraction/plugin mechanism for various reproducers. For instance, the reproducers could register themselves somewhere (if they don't do that already), so we get a list of all of them, similar to how we handle "plugins" now. Then the inspection command could iterate over that list and ask each reproducer component to do its thing. This may be clunky, or it may not, depending on what exactly this "thing" is.