That is fine.
> On Aug 29, 2016, at 11:40 AM, Zachary Turner wrote:
>
> I think the easiest way to do this is to copy the current implementation to
> StdStringExtractor and then have debugserver use that. That only requires
> 1-2 lines of code change in debugserver, and no code change in LLDB
I think the easiest way to do this is to copy the current implementation to
StdStringExtractor and then have debugserver use that. That only requires
1-2 lines of code change in debugserver, and no code change in LLDB. That
way existing code all picks up the new llvm-based implementation, and I c
Making a StringRefExtractor, switching everything over to that, and then
moving StringExtractor to debugserver once everything else is using
StringRefExtractor seems like a reasonable approach
On Mon, Aug 29, 2016 at 11:12 AM Greg Clayton wrote:
>
> > On Aug 29, 2016, at 10:58 AM, Zachary Turner
> On Aug 29, 2016, at 10:58 AM, Zachary Turner wrote:
>
> I don't plan to change debugserver's link requirements. What I'm saying is
> that debugserver is including StringExtractor.h cross-project from LLDB, and
> so even something as simple as including an LLVM header from
> StringExtractor
I don't plan to change debugserver's link requirements. What I'm saying is
that debugserver is including StringExtractor.h cross-project from LLDB,
and so even something as simple as including an LLVM header from
StringExtractor.h will (if I understand correctly) break debugserver. If
I'm correct
> On Aug 27, 2016, at 3:14 PM, Zachary Turner via lldb-dev
> wrote:
>
> What is the status of using LLVM from debugserver? AFAICT, it doesn't use
> llvm, but it DOES use some lldb private libraries, in which case it is
> already implicitly linking against LLVM anyway.
>
> So why can't LLVM
