@@ -2306,6 +2345,11 @@ bool DWARFASTParserClang::CompleteTypeFromDWARF(const
DWARFDIE ,
if (!die)
return false;
+ ParsedDWARFTypeAttributes attrs(die);
ZequanWu wrote:
> The reason why this crash does not happen when attempting to complete a type
>
@@ -2306,6 +2345,11 @@ bool DWARFASTParserClang::CompleteTypeFromDWARF(const
DWARFDIE ,
if (!die)
return false;
+ ParsedDWARFTypeAttributes attrs(die);
ZequanWu wrote:
> Why don't those cases lead to a crash? For example, what would happen if the
>
@@ -2306,6 +2345,11 @@ bool DWARFASTParserClang::CompleteTypeFromDWARF(const
DWARFDIE ,
if (!die)
return false;
+ ParsedDWARFTypeAttributes attrs(die);
ZequanWu wrote:
> How exactly do we get here in that case?
>From
https://github.com/ZequanWu edited
https://github.com/llvm/llvm-project/pull/92328
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -2306,6 +2345,11 @@ bool DWARFASTParserClang::CompleteTypeFromDWARF(const
DWARFDIE ,
if (!die)
return false;
+ ParsedDWARFTypeAttributes attrs(die);
ZequanWu wrote:
The parsing happens every time when constructing this object, which makes it a
@@ -321,6 +326,10 @@ class SymbolFileDWARFDebugMap : public SymbolFileCommon {
std::vector m_func_indexes; // Sorted by address
std::vector m_glob_indexes;
std::map>, OSOInfoSP>
m_oso_map;
+ // A map from CompilerType to the struct/class/union/enum DIE (might be a
+
@@ -2306,6 +2345,11 @@ bool DWARFASTParserClang::CompleteTypeFromDWARF(const
DWARFDIE ,
if (!die)
return false;
+ ParsedDWARFTypeAttributes attrs(die);
ZequanWu wrote:
This extra check was added in https://github.com/llvm/llvm-project/pull/91799
to
https://github.com/ZequanWu edited
https://github.com/llvm/llvm-project/pull/92328
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
ZequanWu wrote:
The second commit is the fix.
https://github.com/llvm/llvm-project/pull/92328
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ZequanWu created
https://github.com/llvm/llvm-project/pull/92328
This reapplies
https://github.com/llvm/llvm-project/commit/9a7262c2601874e5aa64c5db19746770212d4b44
and
https://github.com/llvm/llvm-project/commit/a7eff59f78f08f8ef0487dfe2a136fb311af4fd0
with a fix.
It
ZequanWu wrote:
It actually still crashes at the same place even without this PR using the
following command, you can try it on trunk:
```
$ rm -rf lldb/test/API/commands/expression/import-std-module/lldb-api/*
$ out/cmake/bin/lldb-dotest
ZequanWu wrote:
I had a fix to this: Let `SymbolFileDWARF::GetForwardDeclCompilerTypeToDIE` do
the same as `SymbolFileDWARF::GetUniqueDWARFASTTypeMap`: inquery
SymbolFileDWARFDebugMap first to get the shared underlying SymbolFile so the
map is shared among multiple SymbolFileDWARF. It's
ZequanWu wrote:
> Reverting those two commits seems to have caused this build failure on Ubuntu:
You forgot the delete the newly added test
SymbolFile/DWARF/delayed-definition-die-searching.test in the reverting:
ZequanWu wrote:
> your commit deleted that file I think, I added it back when I did the revert
> (possibly a mistake)... It passes on my macOS system but is failing on
> Ubuntu after the revert. I think I'll just disable it for now.
This change adds the new test, so deleting it as part of
ZequanWu wrote:
> I was able to reproduce the failure of these three:
>
> lldb-api :: lang/c/forward/TestForwardDeclaration.py
> lldb-api :: lang/cpp/unique-types3/TestUniqueTypes3.py
> lldb-api :: types/TestRecursiveTypes.py
>
> locally. Reverting this patch and
>
ZequanWu wrote:
> > Could this commit have broken the bots?
> > https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake/1897/
>
> Looks like so, but I cannot repro the test failure locally.
The error message is different in current latest build
ZequanWu wrote:
> Could this commit have broken the bots?
> https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake/1897/
Looks like so, but I cannot repro the test failure locally.
https://github.com/llvm/llvm-project/pull/90663
___
https://github.com/ZequanWu closed
https://github.com/llvm/llvm-project/pull/91799
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ZequanWu updated
https://github.com/llvm/llvm-project/pull/91799
>From 1f6bf890dbfce07b6ab531597e876ab83cfd1298 Mon Sep 17 00:00:00 2001
From: Zequan Wu
Date: Fri, 10 May 2024 16:00:22 -0400
Subject: [PATCH 1/2] [lldb][DWARF] Do not complete type from declaration die.
---
ZequanWu wrote:
> To the above function to ensure we don't waste any time trying to parse any
> DIE information for forward declaration when using .debug_names. This will
> cause a TON of churn on our DWARF parser and cause us to pull in and parse
> way too much.
That sounds like a better
ZequanWu wrote:
I sent an alternative fix at https://github.com/llvm/llvm-project/pull/91799.
> The .debug_names spec states that only entries with definitions should be in
> the .debug_names table...
Do it mean the .debug_names is implemented incorrectly?
https://github.com/ZequanWu created
https://github.com/llvm/llvm-project/pull/91799
Fix the problem:
https://github.com/llvm/llvm-project/pull/90663#issuecomment-2105164917 by
enhancing a double-check for #90663
>From 1f6bf890dbfce07b6ab531597e876ab83cfd1298 Mon Sep 17 00:00:00 2001
From:
ZequanWu wrote:
> The issue might arise from having a .debug_names table that has DW_IDX_parent
> entries that means that there might be forward declarations included in the
> DWARF index.
Do you mean that the searching in the type index returns a declaration DIE (but
I expected it to always
ZequanWu wrote:
> So this DIE is just a declaration. Shouldn't this code have tried to find a
> non declaration DIE for "std::ios_base"?
Yes, I suppose `SymbolFileDWARF::CompleteType` will try to find the definition
DIE for it before calling `DWARFASTParserClang::CompleteTypeFromDWARF`. If
https://github.com/ZequanWu closed
https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ZequanWu closed
https://github.com/llvm/llvm-project/pull/91343
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -24,13 +24,16 @@ class UniqueDWARFASTType {
UniqueDWARFASTType() : m_type_sp(), m_die(), m_declaration() {}
UniqueDWARFASTType(lldb::TypeSP _sp, const DWARFDIE ,
- const Declaration , int32_t byte_size)
+ const Declaration ,
@@ -0,0 +1,40 @@
+# Test definition DIE searching is delayed until complete type is required.
+
+# RUN: split-file %s %t
+# RUN: %clangxx_host %t/main.cpp %t/t1_def.cpp -g -gsimple-template-names -o
%t.out
+# RUN: %lldb -b %t.out -s %t/lldb.cmd | FileCheck %s
+
+# CHECK:
https://github.com/ZequanWu edited
https://github.com/llvm/llvm-project/pull/91343
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,40 @@
+# Test definition DIE searching is delayed until complete type is required.
+
+# RUN: split-file %s %t
+# RUN: %clangxx_host %t/main.cpp %t/t1_def.cpp -g -gsimple-template-names -o
%t.out
+# RUN: %lldb -b %t.out -s %t/lldb.cmd | FileCheck %s
+
+# CHECK:
@@ -24,13 +24,16 @@ class UniqueDWARFASTType {
UniqueDWARFASTType() : m_type_sp(), m_die(), m_declaration() {}
UniqueDWARFASTType(lldb::TypeSP _sp, const DWARFDIE ,
- const Declaration , int32_t byte_size)
+ const Declaration ,
https://github.com/ZequanWu updated
https://github.com/llvm/llvm-project/pull/90663
>From 4e83099b593e66f12dc21be5fbac5279e03e Mon Sep 17 00:00:00 2001
From: Zequan Wu
Date: Tue, 30 Apr 2024 16:23:11 -0400
Subject: [PATCH 1/8] [lldb][DWARF] Delay struct/class/union definition DIE
ZequanWu wrote:
> > For example:
> > https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp#L922-L927.
> > When parsing function info, it validates low and hi address of the
> > function: `GetMinRangeBase` returns the first range entry base and
ZequanWu wrote:
> > Some places assume the ranges are already sorted but it's not. This fixes
> > it.
>
> What places assumed it was sorted? I assume this means there are some bugs
> that this fixes? Can you give some more details about how you came to write
> this patch?
For example:
ZequanWu wrote:
Will leave it open for few days in case anyone has more comments.
https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ZequanWu edited
https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,40 @@
+# Test definition DIE searching is delayed until complete type is required.
+
+# RUN: split-file %s %t
+# RUN: %clangxx_host %t/main.cpp %t/t1_def.cpp -g -gsimple-template-names -o
%t.out
+# RUN: %lldb -b %t.out -s %t/lldb.cmd | FileCheck %s
+
+# CHECK:
https://github.com/ZequanWu updated
https://github.com/llvm/llvm-project/pull/90663
>From 4e83099b593e66f12dc21be5fbac5279e03e Mon Sep 17 00:00:00 2001
From: Zequan Wu
Date: Tue, 30 Apr 2024 16:23:11 -0400
Subject: [PATCH 1/7] [lldb][DWARF] Delay struct/class/union definition DIE
https://github.com/ZequanWu created
https://github.com/llvm/llvm-project/pull/91343
Dwarf 5 says "There is no requirement that the entries be ordered in any
particular way" in 2.17.3 Non-Contiguous Address Ranges for rnglist. Some
places assume the ranges are already sorted but it's not. This
ZequanWu wrote:
> You could enable logging and check for specific logging after steps. In the
> test I described above if you just print the "Foo *foo" variable, it won't
> need to complete the definition, you could check for logging, and then if you
> print "*foo", then it should complete
@@ -1667,13 +1791,40 @@ DWARFASTParserClang::ParseStructureLikeDIE(const
SymbolContext ,
}
if (dwarf->GetUniqueDWARFASTTypeMap().Find(
-unique_typename, die, unique_decl, attrs.byte_size.value_or(-1),
-*unique_ast_entry_up)) {
+
https://github.com/ZequanWu updated
https://github.com/llvm/llvm-project/pull/90663
>From 4e83099b593e66f12dc21be5fbac5279e03e Mon Sep 17 00:00:00 2001
From: Zequan Wu
Date: Tue, 30 Apr 2024 16:23:11 -0400
Subject: [PATCH 1/6] [lldb][DWARF] Delay struct/class/union definition DIE
https://github.com/ZequanWu closed
https://github.com/llvm/llvm-project/pull/87649
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ZequanWu updated
https://github.com/llvm/llvm-project/pull/90663
>From 4e83099b593e66f12dc21be5fbac5279e03e Mon Sep 17 00:00:00 2001
From: Zequan Wu
Date: Tue, 30 Apr 2024 16:23:11 -0400
Subject: [PATCH 1/5] [lldb][DWARF] Delay struct/class/union definition DIE
ZequanWu wrote:
> > > > > Is any of it testable?
> > > >
> > > >
> > > > Good question. Though this is mostly meant to be "NFC" (with very large
> > > > quotes), I can imagine us doing something like forcing the parsing of a
> > > > specific type (`type lookup ` ?), and then checking that
ZequanWu wrote:
> > > Is any of it testable?
> >
> >
> > Good question. Though this is mostly meant to be "NFC" (with very large
> > quotes), I can imagine us doing something like forcing the parsing of a
> > specific type (`type lookup ` ?), and then checking that the
> > module ast
https://github.com/ZequanWu edited
https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ZequanWu edited
https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1664,13 +1793,40 @@ DWARFASTParserClang::ParseStructureLikeDIE(const
SymbolContext ,
}
if (dwarf->GetUniqueDWARFASTTypeMap().Find(
-unique_typename, die, unique_decl, attrs.byte_size.value_or(-1),
-*unique_ast_entry_up)) {
+
@@ -1921,38 +1970,33 @@ DWARFASTParserClang::ParseStructureLikeDIE(const
SymbolContext ,
GetClangASTImporter().SetRecordLayout(record_decl, layout);
}
}
-} else if (clang_type_was_created) {
- // Start the definition if the class is not
https://github.com/ZequanWu commented:
> Though this is mostly meant to be "NFC" (with very large quotes)
Yeah, this is mostly "NFC". A noticeable difference is we now set the type
created from declaration with `TypeSystemClang::SetHasExternalStorage` without
knowing if there's a definition
@@ -108,6 +108,9 @@ class DWARFASTParserClang : public
lldb_private::plugin::dwarf::DWARFASTParser {
lldb_private::ConstString GetDIEClassTemplateParams(
const lldb_private::plugin::dwarf::DWARFDIE ) override;
ZequanWu wrote:
Done.
@@ -1921,38 +1970,33 @@ DWARFASTParserClang::ParseStructureLikeDIE(const
SymbolContext ,
GetClangASTImporter().SetRecordLayout(record_decl, layout);
}
}
-} else if (clang_type_was_created) {
- // Start the definition if the class is not
@@ -60,6 +60,12 @@ class DWARFASTParser {
virtual ConstString GetDIEClassTemplateParams(const DWARFDIE ) = 0;
+ // Return true if we found the definition DIE for it. is_forward_declaration
+ // is set to true if the parameter die is a declaration.
+ virtual bool
+
@@ -1632,6 +1669,96 @@ DWARFASTParserClang::GetCPlusPlusQualifiedName(const
DWARFDIE ) {
return qualified_name;
}
ZequanWu wrote:
Yes, it does more than finding the DIE. Updated to return `Type*` and renamed
to `FindDefinitionTypeForDIE`.
@@ -16,60 +16,65 @@ using namespace lldb_private::plugin::dwarf;
bool UniqueDWARFASTTypeList::Find(const DWARFDIE ,
const lldb_private::Declaration ,
const int32_t byte_size,
+
@@ -1632,6 +1669,96 @@ DWARFASTParserClang::GetCPlusPlusQualifiedName(const
DWARFDIE ) {
return qualified_name;
}
+bool DWARFASTParserClang::FindDefinitionDIE(const DWARFDIE ,
+bool _forward_declaration) {
@@ -249,11 +270,10 @@ static void ForcefullyCompleteType(CompilerType type) {
/// This function serves a similar purpose as RequireCompleteType above, but it
/// avoids completing the type if it is not immediately necessary. It only
/// ensures we _can_ complete the type
https://github.com/ZequanWu edited
https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ZequanWu updated
https://github.com/llvm/llvm-project/pull/90663
>From 4e83099b593e66f12dc21be5fbac5279e03e Mon Sep 17 00:00:00 2001
From: Zequan Wu
Date: Tue, 30 Apr 2024 16:23:11 -0400
Subject: [PATCH 1/4] [lldb][DWARF] Delay struct/class/union definition DIE
Author: Zequan Wu
Date: 2024-05-02T14:22:03-04:00
New Revision: ee63f287e013ab3424372034d4d5a95512ab5b6b
URL:
https://github.com/llvm/llvm-project/commit/ee63f287e013ab3424372034d4d5a95512ab5b6b
DIFF:
https://github.com/llvm/llvm-project/commit/ee63f287e013ab3424372034d4d5a95512ab5b6b.diff
@@ -1631,13 +1631,19 @@ bool SymbolFileDWARF::CompleteType(CompilerType
_type) {
return true;
}
- DWARFDIE dwarf_die = GetDIE(die_it->getSecond());
+ DWARFDIE dwarf_die = FindDefinitionDIE(GetDIE(die_it->getSecond()));
if (dwarf_die) {
// Once we start
@@ -1654,6 +1660,99 @@ bool SymbolFileDWARF::CompleteType(CompilerType
_type) {
return false;
}
+DWARFDIE SymbolFileDWARF::FindDefinitionDIE(const DWARFDIE ) {
+ auto def_die_it = GetDeclarationDIEToDefinitionDIE().find(die.GetDIE());
+ if (def_die_it !=
@@ -533,9 +540,16 @@ class SymbolFileDWARF : public SymbolFileCommon {
NameToOffsetMap m_function_scope_qualified_name_map;
std::unique_ptr m_ranges;
UniqueDWARFASTTypeMap m_unique_ast_type_map;
+ // A map from DIE to lldb_private::Type. For record type, the key might
https://github.com/ZequanWu updated
https://github.com/llvm/llvm-project/pull/90663
>From 4e83099b593e66f12dc21be5fbac5279e03e Mon Sep 17 00:00:00 2001
From: Zequan Wu
Date: Tue, 30 Apr 2024 16:23:11 -0400
Subject: [PATCH 1/3] [lldb][DWARF] Delay struct/class/union definition DIE
@@ -1654,6 +1660,99 @@ bool SymbolFileDWARF::CompleteType(CompilerType
_type) {
return false;
}
+DWARFDIE SymbolFileDWARF::FindDefinitionDIE(const DWARFDIE ) {
+ auto def_die_it = GetDeclarationDIEToDefinitionDIE().find(die.GetDIE());
+ if (def_die_it !=
ZequanWu wrote:
> Hmm - but the byte size wouldn't be known from only a declaration, right? so
> how'd that key work between a declaration and a definition?
For declaration and definition DIEs, we just look at the name. Byte size and
declaration locations are only used as extra info to
ZequanWu wrote:
> does this cause multiple (an open ended amount?) of declarations for a type
> to be created if the type declarations from multiple CUs are encountered
> separately? Or still only one due to the extra map?
This only creates one even if type declarations are from different
https://github.com/ZequanWu updated
https://github.com/llvm/llvm-project/pull/90663
>From 4e83099b593e66f12dc21be5fbac5279e03e Mon Sep 17 00:00:00 2001
From: Zequan Wu
Date: Tue, 30 Apr 2024 16:23:11 -0400
Subject: [PATCH 1/2] [lldb][DWARF] Delay struct/class/union definition DIE
https://github.com/ZequanWu ready_for_review
https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ZequanWu created
https://github.com/llvm/llvm-project/pull/90663
This is the implementation for
https://discourse.llvm.org/t/rfc-delay-definition-die-searching-when-parse-a-declaration-die-for-record-type/78526.
Motivation
Currently, lldb eagerly searches for
https://github.com/ZequanWu closed
https://github.com/llvm/llvm-project/pull/89427
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ZequanWu edited
https://github.com/llvm/llvm-project/pull/89427
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ZequanWu created
https://github.com/llvm/llvm-project/pull/89427
This removes `m_forward_decl_die_to_compiler_type` which is a map from `const
DWARFDebugInfoEntry *` to `lldb::opaque_compiler_type_t`. This map is currently
used in `DWARFASTParserClang::ParseEnum` and
Author: Zequan Wu
Date: 2024-04-18T11:13:17-04:00
New Revision: d3993ac1890731d2b24543646961c95680788207
URL:
https://github.com/llvm/llvm-project/commit/d3993ac1890731d2b24543646961c95680788207
DIFF:
https://github.com/llvm/llvm-project/commit/d3993ac1890731d2b24543646961c95680788207.diff
Author: Zequan Wu
Date: 2024-04-18T10:40:35-04:00
New Revision: a1e7c83af11ee111994ec19029494e6e9ea97dbd
URL:
https://github.com/llvm/llvm-project/commit/a1e7c83af11ee111994ec19029494e6e9ea97dbd
DIFF:
https://github.com/llvm/llvm-project/commit/a1e7c83af11ee111994ec19029494e6e9ea97dbd.diff
ZequanWu wrote:
Ping.
https://github.com/llvm/llvm-project/pull/87649
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ZequanWu closed
https://github.com/llvm/llvm-project/pull/88792
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -572,9 +572,14 @@ ModuleSP DynamicLoaderPOSIXDYLD::LoadInterpreterModule() {
ModuleSpec module_spec(file, target.GetArchitecture());
if (ModuleSP module_sp = target.GetOrCreateModule(module_spec,
-true /* notify */))
https://github.com/ZequanWu updated
https://github.com/llvm/llvm-project/pull/88792
>From 26528cd679478448edf446e0e82e5f207ffd6113 Mon Sep 17 00:00:00 2001
From: Zequan Wu
Date: Mon, 15 Apr 2024 16:30:38 -0400
Subject: [PATCH 1/5] [lldb][DynamicLoader] Fix lldb unable to stop at
ZequanWu wrote:
> So, could the fix be as simple as passing notify=false in the first call ?
Yeah, absolutely. Updated.
https://github.com/llvm/llvm-project/pull/88792
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://github.com/ZequanWu updated
https://github.com/llvm/llvm-project/pull/88792
>From 26528cd679478448edf446e0e82e5f207ffd6113 Mon Sep 17 00:00:00 2001
From: Zequan Wu
Date: Mon, 15 Apr 2024 16:30:38 -0400
Subject: [PATCH 1/4] [lldb][DynamicLoader] Fix lldb unable to stop at
ZequanWu wrote:
> Can you check where does the second event get sent from? Is it by any chance
> when we go through
> [this](https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp#L460)
> place ?
The first event is sent when
ZequanWu wrote:
> > > why not just call ModulesDidLoad and delegate this (and possibly other
> > > binary-just-loaded) behaviors to it?
> >
> >
> > That's what I did first, but it breaks the test
> > `TestModuleLoadedNotifys.ModuleLoadedNotifysTestCase.test_launch_notifications`
> > because
https://github.com/ZequanWu updated
https://github.com/llvm/llvm-project/pull/88792
>From 26528cd679478448edf446e0e82e5f207ffd6113 Mon Sep 17 00:00:00 2001
From: Zequan Wu
Date: Mon, 15 Apr 2024 16:30:38 -0400
Subject: [PATCH 1/3] [lldb][DynamicLoader] Fix lldb unable to stop at
https://github.com/ZequanWu updated
https://github.com/llvm/llvm-project/pull/88792
>From 26528cd679478448edf446e0e82e5f207ffd6113 Mon Sep 17 00:00:00 2001
From: Zequan Wu
Date: Mon, 15 Apr 2024 16:30:38 -0400
Subject: [PATCH 1/2] [lldb][DynamicLoader] Fix lldb unable to stop at
ZequanWu wrote:
> I'm missing why the _dl_debug_state breakpoint is special here, such that it
> requires a force load of the section info? How does that happen?
Jason's comment explains it well. It's because ld.so's loading is special here.
Normal binaries are loaded via
ZequanWu wrote:
> why not just call ModulesDidLoad and delegate this (and possibly other
> binary-just-loaded) behaviors to it?
That's what I did first, but it breaks the test
`TestModuleLoadedNotifys.ModuleLoadedNotifysTestCase.test_launch_notifications`
because of extra broadcaster event.
https://github.com/ZequanWu created
https://github.com/llvm/llvm-project/pull/88792
If user sets a breakpoint at `_dl_debug_state` before the process launched, the
breakpoint is not resolved yet. When lldb loads dynamic loader module, it's
created with `Target::GetOrCreateModule` which
https://github.com/ZequanWu closed
https://github.com/llvm/llvm-project/pull/86568
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ZequanWu edited
https://github.com/llvm/llvm-project/pull/86568
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ZequanWu edited
https://github.com/llvm/llvm-project/pull/86568
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ZequanWu updated
https://github.com/llvm/llvm-project/pull/86568
>From 19dd9a13c21d70b42b9d68aed6fb0b5a5e494685 Mon Sep 17 00:00:00 2001
From: Zequan Wu
Date: Mon, 25 Mar 2024 15:49:42 -0400
Subject: [PATCH 1/2] [lldb][Dwarf] Fix dwarf parse time for line table and
@@ -1228,10 +1231,9 @@ bool SymbolFileDWARF::ParseLineTable(CompileUnit
_unit) {
if (offset == DW_INVALID_OFFSET)
return false;
- ElapsedTime elapsed(m_parse_time);
ZequanWu wrote:
My understanding is m_parse_time is the time spent only on parsing
https://github.com/ZequanWu created
https://github.com/llvm/llvm-project/pull/86568
`ParseLineTable` not only parses .debug_line but also constructs `LineTable`.
This moves `m_parse_time` into the the function body of `ParseLLVMLineTable` to
more accurately reflect parsing time on
https://github.com/ZequanWu closed
https://github.com/llvm/llvm-project/pull/83192
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ZequanWu created
https://github.com/llvm/llvm-project/pull/83192
If a SetDataBreakpointsRequest contains a list data breakpoints which have
duplicate starting addresses, the current behaviour is returning `{verified:
true}` to both watchpoints with duplicated starting
https://github.com/ZequanWu approved this pull request.
https://github.com/llvm/llvm-project/pull/83162
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ZequanWu closed
https://github.com/llvm/llvm-project/pull/81680
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ZequanWu closed
https://github.com/llvm/llvm-project/pull/81909
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
1 - 100 of 248 matches
Mail list logo
