@@ -107,9 +107,20 @@ def test_process_unload(self):
self, "// Break here", lldb.SBFileSpec("main.cpp")
)
err = lldb.SBError()
-self.process().LoadImage(
-lldb.SBFileSpec(self.getBuildArtifact("libshared.so")), err
-)
+
labath wrote:
So, it took some effort, but I managed to reproduce the problem and figure out
what's going on. You can find my analysis on
https://github.com/llvm/llvm-project/pull/92503
https://github.com/llvm/llvm-project/pull/91321
___
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/92503
…unction (#91321)"
This reapplies fd1bd53ba5a06f344698a55578f6a5d79c457e30, which was reverted due
to a test failure on aarch64/windows. The failure was caused by a combination
of several factors:
- clang
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/92345
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -977,7 +977,7 @@ void request_disconnect(const llvm::json::Object ) {
g_dap.debugger.SetAsync(false);
lldb::SBError error = terminateDebuggee ? process.Kill() :
process.Detach();
if (!error.Success())
- response.try_emplace("error", error.GetCString());
+
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/92341
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
This probably means you can also remove the skipIfWindows decorator, as the
test doesn't actually do anything target-specific.
(It also feels a bit like this is working around something -- I don't see why
not closing a file should cause anything to crash -- but that's probably
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/92252
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
Thanks for checking this out. I'll try to whip something up tomorrow.
https://github.com/llvm/llvm-project/pull/77026
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
Sounds good. Looking forward to it.
https://github.com/llvm/llvm-project/pull/92088
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
labath wrote:
> The problem is here
> lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp, line
> 3235 inside GDBRemoteCommunicationClient::GetFilePermissions()
>
> ```
> file_permissions = mode & (S_IRWXU | S_IRWXG | S_IRWXO);
> ```
Okay, so I think this is the bug. The
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/92090
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
> @skipIfRemote is too much. These tests are still usable for Linux->Linux and
> such.
I don't really care about this, but I'll note that while these tests will run
in a remote configuration, they will not actually test any meaningful property
of the remote setup. They create
Author: Pavel Labath
Date: 2024-05-15T09:18:42Z
New Revision: f090801a9651cf4f0d05cc361a2a1b14805b62bf
URL:
https://github.com/llvm/llvm-project/commit/f090801a9651cf4f0d05cc361a2a1b14805b62bf
DIFF:
https://github.com/llvm/llvm-project/commit/f090801a9651cf4f0d05cc361a2a1b14805b62bf.diff
LOG:
https://github.com/labath closed https://github.com/llvm/llvm-project/pull/92093
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,26 @@
+# REQUIRES: (target-aarch64 || target-arm) && native
+# UNSUPPORTED: system-windows
+
+# RUN: %clang_host %S/Inputs/unaligned-pc-sigbus.c -o %t
+# RUN: %lldb -s %s -o exit %t | FileCheck %s
+
+breakpoint set -n sigbus_handler
+# CHECK: Breakpoint 1: where =
https://github.com/labath updated
https://github.com/llvm/llvm-project/pull/92093
>From 391a4129d3da4c4730e50d6ebca23a3c36c3b462 Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Tue, 14 May 2024 01:27:45 -0700
Subject: [PATCH 1/2] [lldb/aarch64] Allow unaligned PC addresses below a trap
labath wrote:
> > Can we make this less brute force? I believe searching for the Build ID
> > Note should be a completely deterministic process, without the need for
> > heuristics. You start with the elf header, find the program headers,
> > iterate to find the PT_NOTE segment (there could
https://github.com/labath updated
https://github.com/llvm/llvm-project/pull/92137
>From 6d4df820e84e84a871a6d24a196608047470d7d7 Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Tue, 14 May 2024 15:32:15 +
Subject: [PATCH 1/2] [lldb-dap] Correctly detect alias commands with arguments
in
labath wrote:
> The problem is that fstat() is fake on Windows. File::GetPermissions()
> returns 0 always. The test got 'File permissions of /some/file.txt (remote):
> 0o' So any permissions manipulations are useles on Windows and these
> tests cannot be adapted.
But who is calling
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/92137
ResolveCommand will not succeed for an alias command with arguments, and the
code wasn't providing any. Replace that with explicit query(ies) for the
existence of a command with the given name.
>From
labath wrote:
Ah, that explains it. Ship it then.
https://github.com/llvm/llvm-project/pull/92086
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/92086
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
> Ah, so the problem here is that we're missing the eh_frame instructions for
> _sigtramp on arm64 with macOS 14. `signal_generating_add` is a frameless
> function (a great stress test in this instance), and _sigtramp is called with
> enough of a faked-up stack that a stack walk
labath wrote:
I'm currently optimizing our data formatters for some fairly complex data
structures, and I've ran into something I don't understand. My DAP packet
sequence for a hover request consists of two (mostly redundant) packets:
```
-->
Content-Length: 114
{
"arguments": {
@@ -0,0 +1,26 @@
+# REQUIRES: (target-aarch64 || target-arm) && native
+# UNSUPPORTED: system-windows
+
+# RUN: %clang_host %S/Inputs/unaligned-pc-sigbus.c -o %t
+# RUN: %lldb -s %s -o exit %t | FileCheck %s
+
+breakpoint set -n sigbus_handler
+# CHECK: Breakpoint 1: where =
@@ -0,0 +1,26 @@
+# REQUIRES: (target-aarch64 || target-arm) && native
+# UNSUPPORTED: system-windows
+
+# RUN: %clang_host %S/Inputs/unaligned-pc-sigbus.c -o %t
+# RUN: %lldb -s %s -o exit %t | FileCheck %s
+
+breakpoint set -n sigbus_handler
+# CHECK: Breakpoint 1: where =
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/92093
The stack validation heuristic is counter-productive in this case, as the
unaligned address is most likely the thing that caused the signal in the first
place.
>From 391a4129d3da4c4730e50d6ebca23a3c36c3b462 Mon
labath wrote:
Maybe the `skipIfWindows` decorator can also be removed here? We haven't been
historically very good at distinguishing windows hosts and targets (nobody
cared until now), and from the looks of things, these tests could conceivably
work in a linux->windows remote scenario
labath wrote:
Given that the tests use a mock server, why is it a problem that they're
running on a windows host? What's the actual failure? Could they be adapted so
that they run everywhere?
https://github.com/llvm/llvm-project/pull/92088
___
labath wrote:
I'm pretty sure lldb was sending these events at some point, but that could
have change since then. I slightly surprised that this wasn't caught before as
that would mean noone is running these tests remotely.
Jonas, are you running lldb tests in remote configurations?
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/92080
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/92082
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
I like this new version, thanks for sticking with me.
https://github.com/llvm/llvm-project/pull/91887
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
labath wrote:
Can we make this less brute force? I believe searching for the Build ID Note
should be a completely deterministic process, without the need for heuristics.
You start with the elf header, find the program headers, iterate to find the
PT_NOTE segment (there could be more of them),
labath wrote:
> > > LLDB became unresponsive on windows when a `thread backtrace` command was
> > > issued after hitting the exception i have temporarily reverted the change
> > > to make buildbot green.
> >
> >
> > Could you please give me some more information about the problem? I don't
>
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/91944
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
I'm not sure I'm following your reasoning. I'm not saying we should
replace/remove Target::Install. I'm saying we should make everything installed
by Platform::Install executable by default (which, by extension, includes
everything installed by Target::Install, because it
labath wrote:
SGTM. llvm-objcopy is already set in test/API/CMakeLists.txt:88. It should be
straightforward to add llvm-ar as well.
https://github.com/llvm/llvm-project/pull/91942
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
@@ -1654,6 +1654,26 @@ def find_library_callable(test):
)
+def target_install(test, filename=None, path=None):
labath wrote:
This is optional, but I think something like `install_to_target` would be a
better match for the naming style of the
@@ -1654,6 +1654,26 @@ def find_library_callable(test):
)
+def target_install(test, filename=None, path=None):
+test.assertTrue(filename or path, "filename or path must be specified.")
+if filename is None:
+filename = os.path.basename(path)
+if path
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/91931
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/91923
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
> LLDB became unresponsive on windows when a `thread backtrace` command was
> issued after hitting the exception i have temporarily reverted the change to
> make buildbot green.
Could you please give me some more information about the problem? I don't have
access to a windows
labath wrote:
This doesn't sound right. The archive format is a property of the target
system, not the host. It should still be possible to create these kinds of
linux archives, even when running on windows hosts (and vice versa: if we're
running on a linux host, then we won't be able to
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/91886
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath approved this pull request.
Makes sense, although I think that slapping `@skipIfRemote` on the test would
work equally well. AFAICT, this test does not actually care about the remote
(or any other) platform, so there's very little value in running it in these
labath wrote:
> Ah, I misunderstood what the nature of the failure was. I tried running the
> shell test, and it's failing for different reasons. I almost never touch
> shell tests, I find them really hard to debug so I'm not sure what the
> problem is. If I run it by hand,
>
> ```
> (lldb)
labath wrote:
The `ifdef` in the generic code is not exactly ideal, and I'm wondering if we
should just do the same thing as Target::Install does (i.e., set the execute
flag unconditionally). Looking at the history, it appears that the
Target::Install code was
https://github.com/labath closed https://github.com/llvm/llvm-project/pull/91591
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath closed https://github.com/llvm/llvm-project/pull/91586
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
> I can't remember: does terminate come before disconnecting? Or is it the
> other way around?
Disconnect docs say "The disconnect request asks the debug adapter to
disconnect from the debuggee (thus ending the debug session) and then to shut
down itself (the debug adapter).",
labath wrote:
> I realised that as it was, the calling object file would get its map updated
> but not the other object file. Which is potentially a regression if we choose
> to use one or the other file for a lookup. So now the methods update the
> member map, and return the changes they
@@ -23,6 +23,8 @@ class Symtab {
public:
typedef std::vector IndexCollection;
typedef UniqueCStringMap NameToIndexMap;
+ typedef std::map
+ FileAddressToAddressClassMap;
labath wrote:
This code depends on the map being sorted, which densemap isn't.
labath wrote:
I have fixed/worked around the mach exception issue in a [followup
commit](https://github.com/llvm/llvm-project/commit/b903badd73a2467fdd4e363231f2bf9b0704b546)
with a `settings set platform.plugin.darwin.ignored-exceptions
EXC_BAD_INSTRUCTION`. Now the process gets a SIGILL as
labath wrote:
> > I am somewhat worried about this slowing down the actual operations it is
> > reporting progress on. I didn't really measure this, but intuitively, I'd
> > expect that a one of these operations (parsing/importing one type) would be
> > pretty fast, and that the whole process
https://github.com/labath updated
https://github.com/llvm/llvm-project/pull/91586
>From ae3d99727f50be66f2ee0f953c88afd6d22ae8bd Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Thu, 9 May 2024 10:06:11 +
Subject: [PATCH 1/2] [lldb] Improve type name parsing
Parsing of '::' scopes in
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/91591
lldb-dap was setting a flag which was meant to shut it down as soon as it sent
a terminated event. The problem with this flag is two-fold:
- as far as I can tell (definitely not an expert here), there's no
labath wrote:
https://lab.llvm.org/buildbot/#/builders/68/builds/73871 is an example of such
a failure.
https://github.com/llvm/llvm-project/pull/91591
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://github.com/labath approved this pull request.
The change makes sense to me, but this part here got me worried:
> then asked for a better object file, which returned the same program file
> again
Does this mean that we had two ObjectFileELF instances referring to the same
file on disk
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/91586
Parsing of '::' scopes in TypeQuery was very naive and failed for names with
'::''s in template arguments. Interestingly, one of the functions it was
calling (Type::GetTypeScopeAndBasename) was already doing the
labath wrote:
> This looks good to me, I know there are other codepaths that handle this
> correctly, where we can backtrace out of a frameless function that faults
> into a trap handler and we have the entire register state available in the
> trap handler.
>
> Looking at this, I'm a little
Author: Pavel Labath
Date: 2024-05-09T11:40:51Z
New Revision: b903badd73a2467fdd4e363231f2bf9b0704b546
URL:
https://github.com/llvm/llvm-project/commit/b903badd73a2467fdd4e363231f2bf9b0704b546
DIFF:
https://github.com/llvm/llvm-project/commit/b903badd73a2467fdd4e363231f2bf9b0704b546.diff
LOG:
@@ -1411,3 +1414,35 @@ clang::Decl *
ClangASTImporter::ASTImporterDelegate::GetOriginalDecl(clang::Decl *To) {
return m_main.GetDeclOrigin(To).decl;
}
+
+void ClangASTImporter::ASTImporterDelegate::UpdateImportProgress(
labath wrote:
> cast nullptr to a
https://github.com/labath edited https://github.com/llvm/llvm-project/pull/91452
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath commented:
I am somewhat worried about this slowing down the actual operations it is
reporting progress on. I didn't really measure this, but intuitively, I'd
expect that a one of these operations (parsing/importing one type) would be
pretty fast, and that the whole
https://github.com/labath closed https://github.com/llvm/llvm-project/pull/91321
___
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/labath closed https://github.com/llvm/llvm-project/pull/91189
___
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/labath 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/labath approved this pull request.
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
labath wrote:
thanks
https://github.com/llvm/llvm-project/pull/91254
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1555,12 +1555,12 @@ RegisterContextUnwind::SavedLocationForRegister(
}
if (unwindplan_regloc.IsSame()) {
-if (!IsFrameZero() &&
+if (!m_all_registers_available &&
(regnum.GetAsKind(eRegisterKindGeneric) == LLDB_REGNUM_GENERIC_PC ||
@@ -467,7 +465,7 @@ size_t UnwindAssemblyInstEmulation::WriteMemory(
m_pushed_regs[reg_num] = addr;
const int32_t offset = addr - m_initial_sp;
m_curr_row->SetRegisterLocationToAtCFAPlusOffset(reg_num, offset,
-
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/91321
A leaf function may not store the link register to stack, but we it can still
end up being a non-zero frame if it gets interrupted by a signal. Currently, we
were unable to unwind past this function because we
https://github.com/labath updated
https://github.com/llvm/llvm-project/pull/91189
>From 7de5cfcc3016a9e49e289e1009bcf4cc68aa445e Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Mon, 6 May 2024 11:30:59 +
Subject: [PATCH] [lldb] Make SBType::GetDirectNestedType (mostly) work with
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/91189
The implementation is straight-forward, but comes with a big disclaimer. See
#91186 for details.
>From 62f1917a75b4db82470cf5b2721097e6757d5dfb Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Mon, 6 May 2024
@@ -20,9 +20,19 @@ if(LLDB_ENABLE_LUA)
set(lldb_lua_wrapper ${lua_bindings_dir}/LLDBWrapLua.cpp)
endif()
-lldb_tablegen(../../include/lldb/API/SBLanguages.h -gen-lldb-sbapi-dwarf-enum
- SOURCE ${LLVM_MAIN_INCLUDE_DIR}/llvm/BinaryFormat/Dwarf.def
- TARGET
https://github.com/labath closed https://github.com/llvm/llvm-project/pull/90960
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -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)) {
+
@@ -154,6 +154,27 @@ static bool TagIsRecordType(dw_tag_t tag) {
}
}
+static bool
+IsForwardDeclaration(const lldb_private::plugin::dwarf::DWARFDIE ,
labath wrote:
This shouldn't be necessary here, as this file has `using namespace
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/90783
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath 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 (`image dump ast`) does *not* contain
https://github.com/labath updated
https://github.com/llvm/llvm-project/pull/90960
>From f6b47d2763b8217c329c6c5762ed75420ab3579b Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Fri, 3 May 2024 11:18:15 +
Subject: [PATCH] [lldb] Add SBType::GetByteAlign
lldb already mostly(*) tracks this
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/90960
lldb already mostly(*) tracks this information. This just makes it available to
the SB users.
(*) It does not do that for typedefs right now see llvm.org/pr90958
>From 738c13a680b945a0aea1dc762e7122b5ce5608ad
@@ -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
+
@@ -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
@@ -108,6 +108,9 @@ class DWARFASTParserClang : public
lldb_private::plugin::dwarf::DWARFASTParser {
lldb_private::ConstString GetDIEClassTemplateParams(
const lldb_private::plugin::dwarf::DWARFDIE ) override;
labath wrote:
delete
@@ -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
@@ -1632,6 +1669,96 @@ DWARFASTParserClang::GetCPlusPlusQualifiedName(const
DWARFDIE ) {
return qualified_name;
}
+bool DWARFASTParserClang::FindDefinitionDIE(const DWARFDIE ,
+bool _forward_declaration) {
labath
https://github.com/labath commented:
Modulo comments, this makes sense to me (as much as that can ever be said about
this code), but it could definitely use a second (third?) pair of eyes.
Michael, what do you make of this?
https://github.com/llvm/llvm-project/pull/90663
@@ -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/labath 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
@@ -1632,6 +1669,96 @@ DWARFASTParserClang::GetCPlusPlusQualifiedName(const
DWARFDIE ) {
return qualified_name;
}
labath wrote:
I am bothered by this name. I would expect that something called
`FindDefinitionDIE` returns a DWARFDIE (or something along
labath wrote:
FWIW, I agree with @bulbazord. If the user specifies an explicit platform in
the CreateTarget function, that platform should really take precedence over
anything else.
(If it were up to me, I would not even attempt matching other platforms in this
case (and just refuse to create
https://github.com/labath closed https://github.com/llvm/llvm-project/pull/90846
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Pavel Labath
Date: 2024-05-03T06:30:49Z
New Revision: f8fedfb6802173372ec923f99f31d4af810fbcb0
URL:
https://github.com/llvm/llvm-project/commit/f8fedfb6802173372ec923f99f31d4af810fbcb0
DIFF:
https://github.com/llvm/llvm-project/commit/f8fedfb6802173372ec923f99f31d4af810fbcb0.diff
LOG:
https://github.com/labath edited https://github.com/llvm/llvm-project/pull/90622
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,183 @@
+import os
+import shutil
+import tempfile
+
+import lldb
+from lldbsuite.test.decorators import *
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+
+
+"""
+Test support for the DebugInfoD network symbol acquisition protocol.
301 - 400 of 3463 matches
Mail list logo
