[lldb-dev] Slow expression evaluation (ASTImporter is too eager?)

[Jaroslav Sevcik via lldb-dev]

Hello,


I noticed that the AST importer is very eager to import classes/structs
that were already completed, even if they are not needed. This is best
illustrated with an example.

struct C0 { int x = 0; };

struct C1 { int x = 1; C0* c0 = 0; };

struct C2 { int x = 2; C1* c1 = 0; };

int main() {

  C0 c0;

  C1 c1;

  C2 c2;

  return 0;  // break here

}

When we evaluate “c2.x” in LLDB, AST importer completes and imports only
class C2. This is working as intended. Similarly, evaluating “c1.x” imports
just C1 and “c0.x” imports C0. However, if we evaluate “c2.x” after
evaluating “c1.x” and “c0.x”, the importer suddenly imports both C1 and C0
(in addition to C2). See a log from a lldb session at the end of this email
for illustration.

I believe the culprit here is the following code at the end of the
ASTNodeImporter::VisitRecordDecl method:

  if (D->isCompleteDefinition())

if (Error Err = ImportDefinition(D, D2, IDK_Default))

  return std::move(Err);

This will import a definition of class from LLDB if LLDB already happens to
have a complete definition from before. For large programs, this can lead
to importing very large chunks of ASTs even if they are not needed. I have
tried to remove the code above from clang and test performance on several
expressions in an Unreal engine sample - preliminary results show this
could cut down evaluation time by roughly 50%.

My prototype patch is below; note that couple of lldb tests are failing
with a wrong error message, this is a work in progress. What would the
experts here think? Is this a plausible direction?


Cheers, Jaro

diff --git a/clang/lib/AST/ASTImporter.cpp b/clang/lib/AST/ASTImporter.cpp

index 54acca7dc62..ebbce5c66c7 100644

--- a/clang/lib/AST/ASTImporter.cpp

+++ b/clang/lib/AST/ASTImporter.cpp

@@ -2799,7 +2799,7 @@ ExpectedDecl
ASTNodeImporter::VisitRecordDecl(RecordDecl *D) {

   if (D->isAnonymousStructOrUnion())

 D2->setAnonymousStructOrUnion(true);

-  if (D->isCompleteDefinition())

+  if (!Importer.isMinimalImport() && D->isCompleteDefinition())

 if (Error Err = ImportDefinition(D, D2, IDK_Default))

   return std::move(Err);

@@ -3438,6 +3438,9 @@ ExpectedDecl
ASTNodeImporter::VisitFieldDecl(FieldDecl *D) {

   if (ToInitializer)

 ToField->setInClassInitializer(ToInitializer);

   ToField->setImplicit(D->isImplicit());

+  if (CXXRecordDecl *FieldType = D->getType()->getAsCXXRecordDecl())

+   if (Error Err = ImportDefinitionIfNeeded(FieldType))

+ return std::move(Err);

   LexicalDC->addDeclInternal(ToField);

   return ToField;

 }

@@ -5307,7 +5310,7 @@ ExpectedDecl
ASTNodeImporter::VisitClassTemplateSpecializationDecl(

   D2->setTemplateSpecializationKind(D->getTemplateSpecializationKind());

-  if (D->isCompleteDefinition())

+  if (!Importer.isMinimalImport() && D->isCompleteDefinition())

 if (Error Err = ImportDefinition(D, D2))

   return std::move(Err);



—— lldb session illustrating the unnecessary imports —-

This shows that evaluation of “c2.x” after evaluation “c1.x” and “c0.x”
calls to LayoutRecordType for C2, C1 and C0.

$ lldb a.out

(lldb) b h.cc:10

Breakpoint 1: where = a.out`main + 44 at h.cc:10:3, address = ...

(lldb) r

... Process stopped ...

(lldb) log enable lldb expr

(lldb) p c2.x

...

LayoutRecordType[6] ... for (RecordDecl*)0x... [name = 'C2']

...

(lldb) p c1.x

...

LayoutRecordType[7] ... for (RecordDecl*)0x... [name = 'C1']

...

(lldb) p c0.x

...

LayoutRecordType[8] ... for (RecordDecl*)0x... [name = 'C0']

...

(lldb) p c2.x

...

LayoutRecordType[9] ... for (RecordDecl*)0x... [name = 'C2']

LayoutRecordType[10] ... for (RecordDecl*)0x... [name = 'C1']

LayoutRecordType[11] ... for (RecordDecl*)0x... [name = 'C0']

...
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Slow expression evaluation (ASTImporter is too eager?)

[Jaroslav Sevcik via lldb-dev]

Hi Gabor,

you are right, there is something funny going on the LLDB side. Let me
investigate, I will let you know once I know some more.

Cheers, Jaro



On Thu, Nov 7, 2019 at 6:14 PM Gábor Márton  wrote:

> Hi Jaroslav,
>
> Thanks for working on this. Still, there are things that are unclear for
> me.
> I see that `LayoutRecordType` is called superfluously during the second
> evaluation of `c2.x`, ok.
>
> But, could you explain why LLDB is calling that multiple times? Maybe it
> thinks a type is not completed while it is? As far as I know we keep track
> which RecordDecl needs completeion in LLDB. At least, we do not store that
> info in clang::ASTImporter. Minimal import gives a CXXRecordDecl whose
> `DefinitionData` is set, even though the members are not imported the
> definition data is there! So, there is no way for clang::ASTImporter to
> know which RecordDecl had been imported in a minimal way.
>
> I suspect there are multiple invocations of ASTImporter::ImportDefinition
> with C2, C1, C0 within ClangASTSource (could you please check that?). And
> `ImportDefinition` will blindly import the full definitions recursively
> even if the minimal import is set (see ASTNodeImporter::IDK_Everything).
> The patch would change this behavior which I'd like to avoid if possible. I
> think first we should discover why there are multiple invocations of
> ASTImporter::ImportDefinition from within LLDB.
>
> Gabor
>
>
> On Wed, Nov 6, 2019 at 11:21 PM Raphael “Teemperor” Isemann via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Can you post that patch on Phabricator with an '[ASTImporter]’ as a name
>> prefix? This way the ASTImporter folks will see your patch (The ASTImporter
>> is more of a Clang thing, so they might not read lldb-dev). Also it makes
>> it easier to see/test your patch :)
>>
>> (And +Gabor just in case)
>>
>> > On Nov 6, 2019, at 10:25 PM, Jaroslav Sevcik via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>> >
>> > Hello,
>> >
>> > I noticed that the AST importer is very eager to import classes/structs
>> that were already completed, even if they are not needed. This is best
>> illustrated with an example.
>> >
>> > struct C0 { int x = 0; };
>> > struct C1 { int x = 1; C0* c0 = 0; };
>> > struct C2 { int x = 2; C1* c1 = 0; };
>> >
>> > int main() {
>> >   C0 c0;
>> >   C1 c1;
>> >   C2 c2;
>> >
>> >   return 0;  // break here
>> > }
>> >
>> > When we evaluate “c2.x” in LLDB, AST importer completes and imports
>> only class C2. This is working as intended. Similarly, evaluating “c1.x”
>> imports just C1 and “c0.x” imports C0. However, if we evaluate “c2.x” after
>> evaluating “c1.x” and “c0.x”, the importer suddenly imports both C1 and C0
>> (in addition to C2). See a log from a lldb session at the end of this email
>> for illustration.
>> >
>> > I believe the culprit here is the following code at the end of the
>> ASTNodeImporter::VisitRecordDecl method:
>> >
>> >   if (D->isCompleteDefinition())
>> > if (Error Err = ImportDefinition(D, D2, IDK_Default))
>> >   return std::move(Err);
>> >
>> > This will import a definition of class from LLDB if LLDB already
>> happens to have a complete definition from before. For large programs, this
>> can lead to importing very large chunks of ASTs even if they are not
>> needed. I have tried to remove the code above from clang and test
>> performance on several expressions in an Unreal engine sample - preliminary
>> results show this could cut down evaluation time by roughly 50%.
>> >
>> > My prototype patch is below; note that couple of lldb tests are failing
>> with a wrong error message, this is a work in progress. What would the
>> experts here think? Is this a plausible direction?
>> >
>> > Cheers, Jaro
>> >
>> > diff --git a/clang/lib/AST/ASTImporter.cpp
>> b/clang/lib/AST/ASTImporter.cpp
>> > index 54acca7dc62..ebbce5c66c7 100644
>> > --- a/clang/lib/AST/ASTImporter.cpp
>> > +++ b/clang/lib/AST/ASTImporter.cpp
>> > @@ -2799,7 +2799,7 @@ ExpectedDecl
>> ASTNodeImporter::VisitRecordDecl(RecordDecl *D) {
>> >if (D->isAnonymousStructOrUnion())
>> >  D2->setAnonymousStructOrUnion(true);
>> >
>> > -  if (D->isCompleteDefinition())
>> > +  if (!Importer.isMinimalImport() && D->isCompleteDefinition())
>> >  if (Error Err = ImportDefinition(D, D2, IDK_Defau

Re: [lldb-dev] Slow expression evaluation (ASTImporter is too eager?)

[Jaroslav Sevcik via lldb-dev]

why LLDB is calling that multiple times? Maybe it
>> thinks a type is not completed while it is? As far as I know we keep track
>> which RecordDecl needs completeion in LLDB. At least, we do not store that
>> info in clang::ASTImporter. Minimal import gives a CXXRecordDecl whose
>> `DefinitionData` is set, even though the members are not imported the
>> definition data is there! So, there is no way for clang::ASTImporter to
>> know which RecordDecl had been imported in a minimal way.
>>
>> I suspect there are multiple invocations of ASTImporter::ImportDefinition
>> with C2, C1, C0 within ClangASTSource (could you please check that?). And
>> `ImportDefinition` will blindly import the full definitions recursively
>> even if the minimal import is set (see ASTNodeImporter::IDK_Everything).
>> The patch would change this behavior which I'd like to avoid if possible. I
>> think first we should discover why there are multiple invocations of
>> ASTImporter::ImportDefinition from within LLDB.
>>
>> Gabor
>>
>>
>> On Wed, Nov 6, 2019 at 11:21 PM Raphael “Teemperor” Isemann via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> Can you post that patch on Phabricator with an '[ASTImporter]’ as a name
>>> prefix? This way the ASTImporter folks will see your patch (The ASTImporter
>>> is more of a Clang thing, so they might not read lldb-dev). Also it makes
>>> it easier to see/test your patch :)
>>>
>>> (And +Gabor just in case)
>>>
>>> > On Nov 6, 2019, at 10:25 PM, Jaroslav Sevcik via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>> >
>>> > Hello,
>>> >
>>> > I noticed that the AST importer is very eager to import
>>> classes/structs that were already completed, even if they are not needed.
>>> This is best illustrated with an example.
>>> >
>>> > struct C0 { int x = 0; };
>>> > struct C1 { int x = 1; C0* c0 = 0; };
>>> > struct C2 { int x = 2; C1* c1 = 0; };
>>> >
>>> > int main() {
>>> >   C0 c0;
>>> >   C1 c1;
>>> >   C2 c2;
>>> >
>>> >   return 0;  // break here
>>> > }
>>> >
>>> > When we evaluate “c2.x” in LLDB, AST importer completes and imports
>>> only class C2. This is working as intended. Similarly, evaluating “c1.x”
>>> imports just C1 and “c0.x” imports C0. However, if we evaluate “c2.x” after
>>> evaluating “c1.x” and “c0.x”, the importer suddenly imports both C1 and C0
>>> (in addition to C2). See a log from a lldb session at the end of this email
>>> for illustration.
>>> >
>>> > I believe the culprit here is the following code at the end of the
>>> ASTNodeImporter::VisitRecordDecl method:
>>> >
>>> >   if (D->isCompleteDefinition())
>>> > if (Error Err = ImportDefinition(D, D2, IDK_Default))
>>> >   return std::move(Err);
>>> >
>>> > This will import a definition of class from LLDB if LLDB already
>>> happens to have a complete definition from before. For large programs, this
>>> can lead to importing very large chunks of ASTs even if they are not
>>> needed. I have tried to remove the code above from clang and test
>>> performance on several expressions in an Unreal engine sample - preliminary
>>> results show this could cut down evaluation time by roughly 50%.
>>> >
>>> > My prototype patch is below; note that couple of lldb tests are
>>> failing with a wrong error message, this is a work in progress. What would
>>> the experts here think? Is this a plausible direction?
>>> >
>>> > Cheers, Jaro
>>> >
>>> > diff --git a/clang/lib/AST/ASTImporter.cpp
>>> b/clang/lib/AST/ASTImporter.cpp
>>> > index 54acca7dc62..ebbce5c66c7 100644
>>> > --- a/clang/lib/AST/ASTImporter.cpp
>>> > +++ b/clang/lib/AST/ASTImporter.cpp
>>> > @@ -2799,7 +2799,7 @@ ExpectedDecl
>>> ASTNodeImporter::VisitRecordDecl(RecordDecl *D) {
>>> >if (D->isAnonymousStructOrUnion())
>>> >  D2->setAnonymousStructOrUnion(true);
>>> >
>>> > -  if (D->isCompleteDefinition())
>>> > +  if (!Importer.isMinimalImport() && D->isCompleteDefinition())
>>> >  if (Error Err = ImportDefinition(D, D2, IDK_Default))
>>> >return std::move(Err);
>>> >
>>> > @@ -3438,6 +3438,9 @@ ExpectedDecl
>

Re: [lldb-dev] Slow expression evaluation (ASTImporter is too eager?)

[Jaroslav Sevcik via lldb-dev]

import
>> llvm::Expected<...> clang::ASTNodeImporter::importSeq<...>
>> llvm::Expected<...> clang::ASTNodeImporter::importSeq<...>
>> clang::ASTNodeImporter::VisitFieldDecl ;; visit C2::c1
>> clang::declvisitor::Base<...>::Visit
>> clang::ASTImporter::ImportImpl
>> lldb_private::ClangASTImporter::ASTImporterDelegate::ImportImpl
>> clang::ASTImporter::Import
>> llvm::Expected clang::ASTNodeImporter::import
>> clang::ASTNodeImporter::ImportDeclContext
>> clang::ASTImporter::ImportDefinition
>> lldb_private::ClangASTImporter::ASTImporterDelegate::ImportDefinitionTo
>> lldb_private::ClangASTImporter::CompleteTagDecl
>> lldb_private::ClangASTSource::CompleteType ;; complete C2
>> lldb_private::ClangExpressionDeclMap::AddOneVariable
>> lldb_private::ClangExpressionDeclMap::FindExternalVisibleDecls
>> lldb_private::ClangExpressionDeclMap::FindExternalVisibleDecls
>> lldb_private::ClangASTSource::FindExternalVisibleDeclsByName
>>
>> lldb_private::ClangASTSource::ClangASTSourceProxy::FindExternalVisibleDeclsByName
>> clang::DeclContext::lookup const
>> LookupDirect
>> CppNamespaceLookup
>> clang::Sema::CppLookupName
>> clang::Sema::LookupName
>> clang::Sema::BuildUsingDeclaration
>> ...
>>
>>
>> Here is a stack trace that illustrates code gen of types for chain of
>> references.  This was obtain by evaluating c2.x after evaluating c1.x and
>> c0.x
>> in the following program.
>>
>> struct C0 { int x = 0; };
>> struct C1 { int x = 1; C0* c0 = 0; };
>> struct C2 { int x = 2; C1* c1 = 0; };
>>
>> int main() {
>>   C0 c0;
>>   C1 c1;
>>   C2 c2;
>>
>>   return 0;  // break here
>> }
>>
>>
>> ...
>> lldb_private::ClangASTSource::layoutRecordType
>> lldb_private::ClangASTSource::ClangASTSourceProxy::layoutRecordType
>> anonymous namespace)::ItaniumRecordLayoutBuilder::InitializeLayout
>> anonymous namespace)::ItaniumRecordLayoutBuilder::Layout
>> lang::ASTContext::getASTRecordLayout
>> anonymous namespace)::CGRecordLowering::CGRecordLowering
>> anonymous namespace)::CGRecordLowering::CGRecordLowering
>> lang::CodeGen::CodeGenTypes::ComputeRecordLayout
>> lang::CodeGen::CodeGenTypes::ConvertRecordDeclType
>> lang::CodeGen::CodeGenTypes::ConvertType  ;; convert C0
>> clang::CodeGen::CodeGenTypes::ConvertTypeForMem
>> clang::CodeGen::CodeGenTypes::ConvertType ;; convert ptr to C0
>> clang::CodeGen::CodeGenTypes::ConvertTypeForMem
>> (anonymous namespace)::CGRecordLowering::getStorageType
>> (anonymous namespace)::CGRecordLowering::accumulateFields
>> (anonymous namespace)::CGRecordLowering::lower
>> clang::CodeGen::CodeGenTypes::ComputeRecordLayout
>> clang::CodeGen::CodeGenTypes::ConvertRecordDeclType
>> clang::CodeGen::CodeGenTypes::ConvertType ;; convert C1
>> clang::CodeGen::CodeGenTypes::ConvertTypeForMem
>> clang::CodeGen::CodeGenTypes::ConvertType ;; convert ptr to C1
>> clang::CodeGen::CodeGenTypes::ConvertTypeForMem
>> clang::CodeGen::CodeGenModule::GetAddrOfGlobalVar
>> ...
>>
>>
>> On Fri, Nov 8, 2019 at 9:34 PM Jaroslav Sevcik  wrote:
>>
>>> Hi Gabor,
>>>
>>> you are right, there is something funny going on the LLDB side. Let me
>>> investigate, I will let you know once I know some more.
>>>
>>> Cheers, Jaro
>>>
>>>
>>>
>>> On Thu, Nov 7, 2019 at 6:14 PM Gábor Márton 
>>> wrote:
>>>
>>>> Hi Jaroslav,
>>>>
>>>> Thanks for working on this. Still, there are things that are unclear
>>>> for me.
>>>> I see that `LayoutRecordType` is called superfluously during the second
>>>> evaluation of `c2.x`, ok.
>>>>
>>>> But, could you explain why LLDB is calling that multiple times? Maybe
>>>> it thinks a type is not completed while it is? As far as I know we keep
>>>> track which RecordDecl needs completeion in LLDB. At least, we do not store
>>>> that info in clang::ASTImporter. Minimal import gives a CXXRecordDecl whose
>>>> `DefinitionData` is set, even though the members are not imported the
>>>> definition data is there! So, there is no way for clang::ASTImporter to
>>>> know which RecordDecl had been imported in a minimal way.
>>>>
>>>> I suspect there are multiple invocations of
>>>> ASTImporter::ImportDefinition with C2, C1, C0 within ClangASTSource (could
>>>> you please 

Re: [lldb-dev] LLDB sometimes escapes unicode characters, sometimes not

[Jaroslav Sevcik via lldb-dev]

Attempt at a fix: https://reviews.llvm.org/D76650

On Mon, Mar 23, 2020 at 5:22 PM Lutz Justen via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Sorry, the link was internal. Here's the proper on:
>
> https://github.com/llvm-mirror/lldb/blob/master/source/Core/FormatEntity.cpp#L861
>
>
> On Mon, Mar 23, 2020 at 4:00 PM Lutz Justen  wrote:
>
>> Hey,
>>
>> We've noticed that LLDB sometimes escapes certain characters (e.g. in the
>> +128/negative range) of const char* strings and sometimes it doesn't. In
>> particular, this happens for unicode strings:
>>
>> C++:
>> const char* str =  u8"😂";
>>
>> LLDB:
>> (lldb) expr str
>> (const char *) $0 = 0x7ff662489d18 "😂"
>> (lldb) expr (const char*)str
>> (const char *) $1 = 0x7ff662489d18
>> "\xfff0\xff9f\xff98\xff82"
>>
>> To my understanding, evaluating 'str' and '(const char*)str' should be
>> the same since str is already a const char*.
>>
>> We've found that the code takes a different path at this location:
>>
>> https://source.corp.google.com/piper///depot/google3/third_party/llvm/llvm-project/lldb/source/Core/FormatEntity.cpp;l=865;rcl=294541377
>>
>> Any idea what's going on? We'd like to get the unescaped strings. Is it
>> possible to enforce this?
>>
>> Thanks,
>>
>> - Lutz
>>
>> --
>>
>> Dr. Lutz Justen
>>
>> Software Engineer
>>
>> ljus...@google.com
>>
>>
>> Google Germany GmbH
>>
>> ABC-Str. 19
>> 
>>
>> 20354 Hamburg
>> 
>>
>> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
>>
>> Registergericht und -nummer: Hamburg, HRB 86891
>>
>> Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten
>> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
>> löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen,
>> dass die E-Mail an die falsche Person gesendet wurde.
>>
>> This e-mail is confidential. If you received this communication by
>> mistake, please don't forward it to anyone else, please erase all copies
>> and attachments, and please let me know that it has gone to the wrong
>> person.
>>
>>
>> Der Inhalt dieser E-Mail spiegelt den derzeitigen Stand der Verhandlungen
>> wider und dient als Basis für weitere Gespräche. Er soll keine rechtlich
>> verbindliche Verpflichtung begründen. Eine solche Verpflichtung wird allein
>> durch einen zwischen allen beteiligten Parteien abgeschlossenen,
>> schriftlichen Vertrag geschaffen.
>>
>> The above terms reflect a potential business arrangement, are provided
>> solely as a basis for further discussion, and are not intended to be and do
>> not constitute a legally binding obligation. No legally binding obligations
>> will be created, implied, or inferred until an agreement in final form is
>> executed in writing by all parties involved.
>>
>
>
> --
>
> Dr. Lutz Justen
>
> Software Engineer
>
> ljus...@google.com
>
>
> Google Germany GmbH
>
> ABC-Str. 19
> 
>
> 20354 Hamburg
> 
>
> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
>
> Registergericht und -nummer: Hamburg, HRB 86891
>
> Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten
> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
> löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen,
> dass die E-Mail an die falsche Person gesendet wurde.
>
> This e-mail is confidential. If you received this communication by
> mistake, please don't forward it to anyone else, please erase all copies
> and attachments, and please let me know that it has gone to the wrong
> person.
>
>
> Der Inhalt dieser E-Mail spiegelt den derzeitigen Stand der Verhandlungen
> wider und dient als Basis für weitere Gespräche. Er soll keine rechtlich
> verbindliche Verpflichtung begründen. Eine solche Verpflichtung wird allein
> durch einen zwischen allen beteiligten Parteien abgeschlossenen,
> schriftlichen Vertrag geschaffen.
>
> The above terms reflect a potential business arrangement, are provided
> solely as a basis for further discussion, and are not intended to be and do
> not constitute a legally binding obligation. No legally binding obligations
> will be created, implied, or inferred until an agreement in final form is
> executed in writing by all parties involved.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>


-- 

Jaroslav Sevcik |  Software Engineer |  ja...@google.com |

Google Germany GmbH
Erika-Mann-Str. 33
80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado | Registergericht und
-nummer: Hamburg, HRB 86891 | Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adress

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

[Jaroslav Sevcik via lldb-dev]

The svr4 support seems to be off by default:
https://github.com/llvm/llvm-project/blob/2974b3c566d68f1d7c907f891137cf0292dd35aa/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemoteProperties.td#L14

It would definitely make sense to turn it on by default.

- J.


On Thu, May 14, 2020 at 10:13 AM Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> On 14/05/2020 03:50, Emre Kultursay via lldb-dev wrote:
> > One thing I want to try is "settings set
> > plugin.process.gdb-remote.use-libraries-svr4 true".
>
> Isn't that the default? The reason this setting was added was so we
> could test the !svr code path without forcibly disabling xml support
> (and possibly workaround any svr issues). However, having it on as a
> default definitely makes sense?
>

> pl
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>


-- 

Jaroslav Sevcik |  Software Engineer |  ja...@google.com |

Google Germany GmbH
Erika-Mann-Str. 33
80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado | Registergericht und
-nummer: Hamburg, HRB 86891 | Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind,
leiten Sie diese bitte nicht weiter, informieren Sie den Absender und
löschen Sie die E-Mail und alle Anhänge. Vielen Dank.

This e-mail is confidential. If you are not the right addressee please do
not forward it, please inform the sender, and please erase this e-mail
including any attachments. Thanks.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev