================
@@ -965,6 +965,22 @@ SBTarget SBDebugger::GetDummyTarget() {
return sb_target;
}
+void SBDebugger::DispatchClientTelemetry(const lldb::SBStructuredData &entry) {
+ LLDB_INSTRUMENT_VA(this);
+ // Disable client-telemetry for SWIG.
+ // This prevent arbitrary python client (pretty printers, whatnot) from
sending
+ // telemetry without vendors knowing.
+#ifndef SWIG
----------------
labath wrote:
I have a feeling this is recreating a small version of the `#ifdef TELEMETRY`
hell we've escaped only recently. I can definitely understand the desire/need
to restrict access to this API to the world outside (lib)lldb. However, does
that have to be achieved by deleting the function declaration? Could it be
enough to have the declaration unconditionally, but put the implementation
behind some build-time flag (or even a runtime flag that's controlled by the
telemetry plugin -- and have the downstream implementation never set it)? (this
question is mainly for Jonas. I'm aware you didn't ask for support for this to
be added upstream, but I think Vy's attempt to do that demonstrates the kind of
problems you're setting yourself up for if you choose that strategy. I think it
be better to figure out a different solution, as I think you won't be the only
one with that concern.)
Vy: note that this question is independent of the question whether to expose
the function to python. `ifdef SWIG` prevents SWIG from seeing a function (so
it doesn't generate bindings for it). The function will always be present in
the binary. This is why SWIG guard doesn't have to be applied to function
bodies as the swig never reads those. I'm pretty sure this is what Jonas meant
when he suggested moving the ifdef to the header -- search for other instances
of `#ifndef SWIG`
https://github.com/llvm/llvm-project/pull/129728
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
