[Lldb-commits] [PATCH] D26188: [RFC] Solve linking inconsistency, proposal one

Pavel Labath via lldb-commits lldb-commits at lists.llvm.org
Tue Nov 1 08:33:02 PDT 2016

labath added a comment.

In https://reviews.llvm.org/D26188#584614, @tfiala wrote:

> I'll let Greg comment on the public ABI expansion (i.e. including llvm of a specific version, which may differ from LLDB.framework clients that contain different versions of LLVM).  My guess is this is not going to work for us, since we have long-lived frameworks shipped with Xcode that get used by clients where we cannot assume what they are or are not using.  However, we could address that by adding the reverse flag, which would be "don't export LLVM", and have that be exported by default.

I'd like to avoid that, as it means we will have to have two completely different ways of linking lldb-mi (and maybe lldb, if it starts using some llvm APIs -- it already does on windows, mostly accidentally). I'd rather stick to the proposal two then.

> The bit I care about is the "modulo backtrace(3)..." part.  This change is taking away my ability to use log-based stacktraces on Linux if I read it right.  How were you envisioning I do that with this change?

This does not affect affect the state of backtracing. The option to export all symbols could still stay there, and maybe could even be the default. The "modulo" part was about the fact that this would not be a _completely_ side-effect free optimisation, as it would affect the backtracing.


More information about the lldb-commits mailing list