Details
Diff Detail
Event Timeline
lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp | ||
---|---|---|
138 | Why did we end up with a multiprocess extension? I'd think that support for that is implemented completely inside the gdb-remote class, and there's no need to advertise it's availability by the process plugin? |
lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp | ||
---|---|---|
138 | Primarily to make things more consistent and to avoid confusion. For example, right now LLGS strips away extensions that are not supported by the plugin. If plugin didn't report Extension::multiprocess, we'd have to add more special cases to the LLGS code. |
lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp | ||
---|---|---|
138 | I, for one, am confused by it being present here. :) The consistency argument might make sense if this was the only protocol-level feature, but I can see at least several others which are implemented by the LLGS class: (PacketSize, QStartNoAckMode, vContSupported). |
lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp | ||
---|---|---|
138 | Well, I think the main difference is that this one actually takes active part in client-server exchange. I can make a patch later to make it unconditional but I'm not sure if you're going to like the implications. |
Why did we end up with a multiprocess extension? I'd think that support for that is implemented completely inside the gdb-remote class, and there's no need to advertise it's availability by the process plugin?