This revision was automatically updated to reflect the committed changes.
Closed by commit rL285894: Link lldb-mi only to the llvm components it uses
(authored by labath).
Changed prior to commit:
https://reviews.llvm.org/D26190?vs=76554&id=76833#toc
Repository:
rL LLVM
https://reviews.llvm
labath added a comment.
In https://reviews.llvm.org/D26190#585106, @mehdi_amini wrote:
> >> , but LLVM is not robust to mix and match build settings: building half of
> >> the source with -DNDEBUG and not the other is likely to cause weird
> >> runtime failures. That can be an issue because now
mehdi_amini added a comment.
Just to clarify: I don't have a dog in this, I'm just lurking here to learn
something, and I'm curious about the tradeoff.
In https://reviews.llvm.org/D26190#585059, @labath wrote:
> In https://reviews.llvm.org/D26190#585016, @mehdi_amini wrote:
>
> > > Does that ma
labath added a comment.
In https://reviews.llvm.org/D26190#585016, @mehdi_amini wrote:
> > Does that make sense?
>
> This makes sense (assuming static linking reduces some possibility though)
I am not sure we are on the same page here. What is the scenario you have in
mind here? I am not forbi
mehdi_amini added a comment.
> Does that make sense?
This makes sense (assuming static linking reduces some possibility though), but
LLVM is not robust to mix and match build settings: building half of the source
with -DNDEBUG and not the other is likely to cause weird runtime failures. That
c
jingham added a comment.
Note that in this proposal, lldb is doing pretty much the same thing that
libclang does. libclang exports its specific functionality but makes no
attempt to export the llvm classes it uses. The only difference is that lldb
exports a tightly controlled C++ API, whereas
labath added a comment.
In https://reviews.llvm.org/D26190#584933, @mehdi_amini wrote:
> OK!
>
> How is it different from the other proposal? In the other proposal, using a
> LLVM class in the API boundary would break the same way under the same
> conditions, or did I miss something?
In the o
mehdi_amini added a comment.
OK!
How is it different from the other proposal? In the other proposal, using a
LLVM class in the API boundary would break the same way under the same
conditions, or did I miss something?
Something that isn't clear to me with this proposal, is how a user supposed t
labath added a comment.
In https://reviews.llvm.org/D26190#584882, @mehdi_amini wrote:
> > and has potential to introduce latent bugs.
>
> Can you elaborate on this?
If some of the duplicated objects get passed across the api boundary, things
will start to break, although the breakage may not
mehdi_amini added a comment.
> and has potential to introduce latent bugs.
Can you elaborate on this?
https://reviews.llvm.org/D26190
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-comm
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
I prefer this solution for now over exporting all of llvm. The other solution
introduces fragility in a shared library that currently vends a solid reliable
API.
https://reviews.llvm.org
labath created this revision.
labath added reviewers: beanz, zturner, tfiala, clayborg, abidh.
labath added a subscriber: lldb-commits.
Herald added subscribers: mgorny, ki.stfu.
This "solves" the ODR violations by making the linker firewall a feature. llvm
libraries used by liblldb are considered
12 matches
Mail list logo
