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.


https://reviews.llvm.org/D26188



_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to