mgorny added inline comments.
================
Comment at: lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp:138
+NativeProcessNetBSD::Factory::GetSupportedExtensions() const {
+ return Extension::multiprocess | Extension::fork | Extension::vfork;
+}
----------------
labath wrote:
> mgorny wrote:
> > labath wrote:
> > > 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?
> > 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.
> 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).
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.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D100554/new/
https://reviews.llvm.org/D100554
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
