[Lldb-commits] [lldb] [lldb][ELF] Move address class map into the symbol table (PR #91603)
@@ -23,6 +23,8 @@ class Symtab {
public:
typedef std::vector IndexCollection;
typedef UniqueCStringMap NameToIndexMap;
+ typedef std::map
+ FileAddressToAddressClassMap;
clayborg wrote:
You might want to use a llvm::DenseMap if possible. std::map uses 3 pointers
for the red/black tree implementation and DenseMap is much more efficient I
believe.
https://github.com/llvm/llvm-project/pull/91603
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Fix a race during shutdown (PR #91591)
https://github.com/clayborg commented: I can't remember: does terminate come before disconnecting? Or is it the other way around? 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
[Lldb-commits] [lldb] [WIP] [lldb][Progress] Report progress when completing types from DWARF (PR #91452)
https://github.com/clayborg commented: How many notifications happen during an expression? We want to make sure this doesn't slow down expression evaluation by any appreciable amount. If we spam these notifications, without having any throttling in place (I have an open patch for this I haven't been getting back to: https://github.com/llvm/llvm-project/pull/75769) I fear this will cause things to slow down a bit. I know IDEs are more sensitive to being blasted with progress updates. 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
[Lldb-commits] [lldb] [lldb] Put SBSourceLanguageName in lldb namespace (PR #91685)
https://github.com/JDevlieghere approved this pull request. https://github.com/llvm/llvm-project/pull/91685 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Allow env override for LLDB_ARGDUMPER_PATH (PR #91688)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Keith Smiley (keith)
Changes
This mirrors the LLDB_DEBUGSERVER_PATH environment variable and allows you to
have lldb-argdumper in a non-standard location and still use it at runtime.
---
Full diff: https://github.com/llvm/llvm-project/pull/91688.diff
1 Files Affected:
- (modified) lldb/source/Host/macosx/objcxx/Host.mm (+24-11)
``diff
diff --git a/lldb/source/Host/macosx/objcxx/Host.mm
b/lldb/source/Host/macosx/objcxx/Host.mm
index 4fba5550ba10a..e6f1c0ea3d295 100644
--- a/lldb/source/Host/macosx/objcxx/Host.mm
+++ b/lldb/source/Host/macosx/objcxx/Host.mm
@@ -1387,18 +1387,31 @@ static bool ShouldLaunchUsingXPC(ProcessLaunchInfo
_info) {
Status Host::ShellExpandArguments(ProcessLaunchInfo _info) {
Status error;
if (launch_info.GetFlags().Test(eLaunchFlagShellExpandArguments)) {
-FileSpec expand_tool_spec = HostInfo::GetSupportExeDir();
-if (!expand_tool_spec) {
- error.SetErrorString(
- "could not get support executable directory for lldb-argdumper
tool");
- return error;
+FileSpec expand_tool_spec;
+Environment host_env = Host::GetEnvironment();
+std::string env_argdumper_path = host_env.lookup("LLDB_ARGDUMPER_PATH");
+if (!env_argdumper_path.empty()) {
+ expand_tool_spec.SetFile(env_argdumper_path, FileSpec::Style::native);
+ Log *log(GetLog(LLDBLog::Host | LLDBLog::Process));
+ LLDB_LOGF(log,
+"lldb-argdumper exe path set from environment variable: %s",
+env_argdumper_path.c_str());
}
-expand_tool_spec.AppendPathComponent("lldb-argdumper");
-if (!FileSystem::Instance().Exists(expand_tool_spec)) {
- error.SetErrorStringWithFormat(
- "could not find the lldb-argdumper tool: %s",
- expand_tool_spec.GetPath().c_str());
- return error;
+bool argdumper_exists = FileSystem::Instance().Exists(env_argdumper_path);
+if (!argdumper_exists) {
+ expand_tool_spec = HostInfo::GetSupportExeDir();
+ if (!expand_tool_spec) {
+error.SetErrorString("could not get support executable directory for "
+ "lldb-argdumper tool");
+return error;
+ }
+ expand_tool_spec.AppendPathComponent("lldb-argdumper");
+ if (!FileSystem::Instance().Exists(expand_tool_spec)) {
+error.SetErrorStringWithFormat(
+"could not find the lldb-argdumper tool: %s",
+expand_tool_spec.GetPath().c_str());
+return error;
+ }
}
StreamString expand_tool_spec_stream;
``
https://github.com/llvm/llvm-project/pull/91688
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Allow env override for LLDB_ARGDUMPER_PATH (PR #91688)
https://github.com/keith created https://github.com/llvm/llvm-project/pull/91688
This mirrors the LLDB_DEBUGSERVER_PATH environment variable and allows you to
have lldb-argdumper in a non-standard location and still use it at runtime.
>From 98ddf4ed99a10c46a43d9a750bd826623a8c7e6f Mon Sep 17 00:00:00 2001
From: Keith Smiley
Date: Thu, 9 May 2024 18:10:36 -0700
Subject: [PATCH] [lldb] Allow env override for LLDB_ARGDUMPER_PATH
This mirrors the LLDB_DEBUGSERVER_PATH environment variable and allows
you to have lldb-argdumper in a non-standard location and still use it
at runtime.
---
lldb/source/Host/macosx/objcxx/Host.mm | 35 ++
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/lldb/source/Host/macosx/objcxx/Host.mm
b/lldb/source/Host/macosx/objcxx/Host.mm
index 4fba5550ba10a..e6f1c0ea3d295 100644
--- a/lldb/source/Host/macosx/objcxx/Host.mm
+++ b/lldb/source/Host/macosx/objcxx/Host.mm
@@ -1387,18 +1387,31 @@ static bool ShouldLaunchUsingXPC(ProcessLaunchInfo
_info) {
Status Host::ShellExpandArguments(ProcessLaunchInfo _info) {
Status error;
if (launch_info.GetFlags().Test(eLaunchFlagShellExpandArguments)) {
-FileSpec expand_tool_spec = HostInfo::GetSupportExeDir();
-if (!expand_tool_spec) {
- error.SetErrorString(
- "could not get support executable directory for lldb-argdumper
tool");
- return error;
+FileSpec expand_tool_spec;
+Environment host_env = Host::GetEnvironment();
+std::string env_argdumper_path = host_env.lookup("LLDB_ARGDUMPER_PATH");
+if (!env_argdumper_path.empty()) {
+ expand_tool_spec.SetFile(env_argdumper_path, FileSpec::Style::native);
+ Log *log(GetLog(LLDBLog::Host | LLDBLog::Process));
+ LLDB_LOGF(log,
+"lldb-argdumper exe path set from environment variable: %s",
+env_argdumper_path.c_str());
}
-expand_tool_spec.AppendPathComponent("lldb-argdumper");
-if (!FileSystem::Instance().Exists(expand_tool_spec)) {
- error.SetErrorStringWithFormat(
- "could not find the lldb-argdumper tool: %s",
- expand_tool_spec.GetPath().c_str());
- return error;
+bool argdumper_exists = FileSystem::Instance().Exists(env_argdumper_path);
+if (!argdumper_exists) {
+ expand_tool_spec = HostInfo::GetSupportExeDir();
+ if (!expand_tool_spec) {
+error.SetErrorString("could not get support executable directory for "
+ "lldb-argdumper tool");
+return error;
+ }
+ expand_tool_spec.AppendPathComponent("lldb-argdumper");
+ if (!FileSystem::Instance().Exists(expand_tool_spec)) {
+error.SetErrorStringWithFormat(
+"could not find the lldb-argdumper tool: %s",
+expand_tool_spec.GetPath().c_str());
+return error;
+ }
}
StreamString expand_tool_spec_stream;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add CMake dependency tracking for SBLanguages generation script (PR #91686)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Alex Langford (bulbazord)
Changes
If you change the generation script and re-run ninja (or whatever drives your
build), it currently will not regenerate SBLanguages.h. With dependency
tracking, it should re-run when the script changes.
---
Full diff: https://github.com/llvm/llvm-project/pull/91686.diff
1 Files Affected:
- (modified) lldb/source/API/CMakeLists.txt (+4-1)
``diff
diff --git a/lldb/source/API/CMakeLists.txt b/lldb/source/API/CMakeLists.txt
index aa31caddfde3a..76b42ecf63f91 100644
--- a/lldb/source/API/CMakeLists.txt
+++ b/lldb/source/API/CMakeLists.txt
@@ -23,14 +23,17 @@ endif()
# Generate SBLanguages.h from Dwarf.def.
set(sb_languages_file
${CMAKE_CURRENT_BINARY_DIR}/../../include/lldb/API/SBLanguages.h)
+set(sb_languages_generator
+ ${LLDB_SOURCE_DIR}/scripts/generate-sbapi-dwarf-enum.py)
add_custom_command(
COMMENT "Generating SBLanguages.h from Dwarf.def"
COMMAND "${Python3_EXECUTABLE}"
- ${LLDB_SOURCE_DIR}/scripts/generate-sbapi-dwarf-enum.py
+ ${sb_languages_generator}
${LLVM_MAIN_INCLUDE_DIR}/llvm/BinaryFormat/Dwarf.def
-o ${sb_languages_file}
OUTPUT ${sb_languages_file}
DEPENDS ${LLVM_MAIN_INCLUDE_DIR}/llvm/BinaryFormat/Dwarf.def
+ ${sb_languages_generator}
WORKING_DIRECTORY ${LLVM_LIBRARY_OUTPUT_INTDIR}
)
add_custom_target(lldb-sbapi-dwarf-enums
``
https://github.com/llvm/llvm-project/pull/91686
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add CMake dependency tracking for SBLanguages generation script (PR #91686)
https://github.com/bulbazord created
https://github.com/llvm/llvm-project/pull/91686
If you change the generation script and re-run ninja (or whatever drives your
build), it currently will not regenerate SBLanguages.h. With dependency
tracking, it should re-run when the script changes.
>From ba9f8753702fee417f2d00321a40d80dfb025795 Mon Sep 17 00:00:00 2001
From: Alex Langford
Date: Thu, 9 May 2024 17:37:08 -0700
Subject: [PATCH] [lldb] Add CMake dependency tracking for SBLanguages
generation script
If you change the generation script and re-run ninja (or whatever
drives your build), it currently will not regenerate SBLanguages.h.
With dependency tracking, it should re-run when the script changes.
---
lldb/source/API/CMakeLists.txt | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lldb/source/API/CMakeLists.txt b/lldb/source/API/CMakeLists.txt
index aa31caddfde3a..76b42ecf63f91 100644
--- a/lldb/source/API/CMakeLists.txt
+++ b/lldb/source/API/CMakeLists.txt
@@ -23,14 +23,17 @@ endif()
# Generate SBLanguages.h from Dwarf.def.
set(sb_languages_file
${CMAKE_CURRENT_BINARY_DIR}/../../include/lldb/API/SBLanguages.h)
+set(sb_languages_generator
+ ${LLDB_SOURCE_DIR}/scripts/generate-sbapi-dwarf-enum.py)
add_custom_command(
COMMENT "Generating SBLanguages.h from Dwarf.def"
COMMAND "${Python3_EXECUTABLE}"
- ${LLDB_SOURCE_DIR}/scripts/generate-sbapi-dwarf-enum.py
+ ${sb_languages_generator}
${LLVM_MAIN_INCLUDE_DIR}/llvm/BinaryFormat/Dwarf.def
-o ${sb_languages_file}
OUTPUT ${sb_languages_file}
DEPENDS ${LLVM_MAIN_INCLUDE_DIR}/llvm/BinaryFormat/Dwarf.def
+ ${sb_languages_generator}
WORKING_DIRECTORY ${LLVM_LIBRARY_OUTPUT_INTDIR}
)
add_custom_target(lldb-sbapi-dwarf-enums
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Put SBSourceLanguageName in lldb namespace (PR #91685)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Alex Langford (bulbazord)
Changes
---
Full diff: https://github.com/llvm/llvm-project/pull/91685.diff
1 Files Affected:
- (modified) lldb/scripts/generate-sbapi-dwarf-enum.py (+4)
``diff
diff --git a/lldb/scripts/generate-sbapi-dwarf-enum.py
b/lldb/scripts/generate-sbapi-dwarf-enum.py
index f7a13e5efffef..7fd6037986317 100755
--- a/lldb/scripts/generate-sbapi-dwarf-enum.py
+++ b/lldb/scripts/generate-sbapi-dwarf-enum.py
@@ -15,6 +15,8 @@
#ifndef LLDB_API_SBLANGUAGE_H
#define LLDB_API_SBLANGUAGE_H
+
+namespace lldb {
/// Used by \\ref SBExpressionOptions.
/// These enumerations use the same language enumerations as the DWARF
/// specification for ease of use and consistency.
@@ -24,6 +26,8 @@
FOOTER = """\
};
+} // namespace lldb
+
#endif
"""
``
https://github.com/llvm/llvm-project/pull/91685
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Put SBSourceLanguageName in lldb namespace (PR #91685)
https://github.com/bulbazord created
https://github.com/llvm/llvm-project/pull/91685
None
>From 6c2ea1ff493a55fc4713c4bc58ef6e659e1c7b9d Mon Sep 17 00:00:00 2001
From: Alex Langford
Date: Thu, 9 May 2024 17:27:42 -0700
Subject: [PATCH] [lldb] Put SBSourceLanguageName in lldb namespace
---
lldb/scripts/generate-sbapi-dwarf-enum.py | 4
1 file changed, 4 insertions(+)
diff --git a/lldb/scripts/generate-sbapi-dwarf-enum.py
b/lldb/scripts/generate-sbapi-dwarf-enum.py
index f7a13e5efffef..7fd6037986317 100755
--- a/lldb/scripts/generate-sbapi-dwarf-enum.py
+++ b/lldb/scripts/generate-sbapi-dwarf-enum.py
@@ -15,6 +15,8 @@
#ifndef LLDB_API_SBLANGUAGE_H
#define LLDB_API_SBLANGUAGE_H
+
+namespace lldb {
/// Used by \\ref SBExpressionOptions.
/// These enumerations use the same language enumerations as the DWARF
/// specification for ease of use and consistency.
@@ -24,6 +26,8 @@
FOOTER = """\
};
+} // namespace lldb
+
#endif
"""
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][breakpoint] Grey out disabled breakpoints (PR #91404)
https://github.com/chelcassanova updated
https://github.com/llvm/llvm-project/pull/91404
>From 0e45adeac968aa435f58dfef026ef308e56b40a5 Mon Sep 17 00:00:00 2001
From: Chelsea Cassanova
Date: Thu, 9 May 2024 11:08:29 -0700
Subject: [PATCH] [lldb][breakpoint] Grey out disabled breakpoints
This commit adds colour settings to the list of breakpoints in order to
grey out breakpoints that have been disabled.
---
lldb/source/Breakpoint/Breakpoint.cpp | 12
1 file changed, 12 insertions(+)
diff --git a/lldb/source/Breakpoint/Breakpoint.cpp
b/lldb/source/Breakpoint/Breakpoint.cpp
index ae845e92762b9..8d28c5f1873e1 100644
--- a/lldb/source/Breakpoint/Breakpoint.cpp
+++ b/lldb/source/Breakpoint/Breakpoint.cpp
@@ -15,6 +15,7 @@
#include "lldb/Breakpoint/BreakpointResolver.h"
#include "lldb/Breakpoint/BreakpointResolverFileLine.h"
#include "lldb/Core/Address.h"
+#include "lldb/Core/Debugger.h"
#include "lldb/Core/Module.h"
#include "lldb/Core/ModuleList.h"
#include "lldb/Core/SearchFilter.h"
@@ -26,6 +27,7 @@
#include "lldb/Target/SectionLoadList.h"
#include "lldb/Target/Target.h"
#include "lldb/Target/ThreadSpec.h"
+#include "lldb/Utility/AnsiTerminal.h"
#include "lldb/Utility/LLDBLog.h"
#include "lldb/Utility/Log.h"
#include "lldb/Utility/Stream.h"
@@ -837,6 +839,12 @@ void Breakpoint::GetDescription(Stream *s,
lldb::DescriptionLevel level,
bool show_locations) {
assert(s != nullptr);
+ // Grey out any disabled breakpoints in the list of breakpoints.
+ const bool print_faint =
+ (!IsEnabled() && GetTarget().GetDebugger().GetUseColor());
+ if (print_faint)
+s->Printf("%s", ansi::FormatAnsiTerminalCodes("${ansi.faint}").c_str());
+
if (!m_kind_description.empty()) {
if (level == eDescriptionLevelBrief) {
s->PutCString(GetBreakpointKind());
@@ -933,6 +941,10 @@ void Breakpoint::GetDescription(Stream *s,
lldb::DescriptionLevel level,
}
s->IndentLess();
}
+
+ // Reset the colors back to normal if they were previously greyed out.
+ if (print_faint)
+s->Printf("%s", ansi::FormatAnsiTerminalCodes("${ansi.normal}").c_str());
}
void Breakpoint::GetResolverDescription(Stream *s) {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Unify CalculateMD5 return types (PR #91029)
https://github.com/JDevlieghere closed https://github.com/llvm/llvm-project/pull/91029 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 95f208f - [lldb] Unify CalculateMD5 return types (#91029)
Author: Anthony Ha
Date: 2024-05-09T15:57:46-07:00
New Revision: 95f208f97e709139c3ecbce552bcf1e34b9fcf12
URL:
https://github.com/llvm/llvm-project/commit/95f208f97e709139c3ecbce552bcf1e34b9fcf12
DIFF:
https://github.com/llvm/llvm-project/commit/95f208f97e709139c3ecbce552bcf1e34b9fcf12.diff
LOG: [lldb] Unify CalculateMD5 return types (#91029)
This is a retake of https://github.com/llvm/llvm-project/pull/90921
which got reverted because I forgot to modify the CalculateMD5 unit test
I had added in https://github.com/llvm/llvm-project/pull/88812
The prior failing build is here:
https://lab.llvm.org/buildbot/#/builders/68/builds/73622
To make sure this error doesn't happen, I ran `ninja
ProcessGdbRemoteTests` and then executed the resulting test binary and
observed the `CalculateMD5` test passed.
# Overview
In my previous PR: https://github.com/llvm/llvm-project/pull/88812,
@JDevlieghere suggested to match return types of the various calculate
md5 functions.
This PR achieves that by changing the various calculate md5 functions to
return `llvm::ErrorOr`.
The suggestion was to go for `std::optional<>` but I opted for
`llvm::ErrorOr<>` because local calculate md5 was already possibly
returning `ErrorOr`.
To make sure I didn't break the md5 calculation functionality, I ran
some tests for the gdb remote client, and things seem to work.
# Testing
1. Remote file doesn't exist
1. Remote file differs
1. Remote file matches
## Test gaps
Unfortunately, I had to modify
`lldb/source/Plugins/Platform/MacOSX/PlatformDarwinDevice.cpp` and I
can't test the changes there. Hopefully, the existing test suite / code
review from whomever is reading this will catch any issues.
Added:
Modified:
lldb/include/lldb/Target/Platform.h
lldb/include/lldb/Target/RemoteAwarePlatform.h
lldb/source/Plugins/Platform/MacOSX/PlatformDarwinDevice.cpp
lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp
lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.h
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
lldb/source/Target/Platform.cpp
lldb/source/Target/RemoteAwarePlatform.cpp
lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
Removed:
diff --git a/lldb/include/lldb/Target/Platform.h
b/lldb/include/lldb/Target/Platform.h
index ad9c9dcbe684b..e05c79cb501bf 100644
--- a/lldb/include/lldb/Target/Platform.h
+++ b/lldb/include/lldb/Target/Platform.h
@@ -649,8 +649,8 @@ class Platform : public PluginInterface {
virtual std::string GetPlatformSpecificConnectionInformation() { return ""; }
- virtual bool CalculateMD5(const FileSpec _spec, uint64_t ,
-uint64_t );
+ virtual llvm::ErrorOr
+ CalculateMD5(const FileSpec _spec);
virtual uint32_t GetResumeCountForLaunchInfo(ProcessLaunchInfo _info)
{
return 1;
diff --git a/lldb/include/lldb/Target/RemoteAwarePlatform.h
b/lldb/include/lldb/Target/RemoteAwarePlatform.h
index d183815e1c8b0..0b9d79f9ff038 100644
--- a/lldb/include/lldb/Target/RemoteAwarePlatform.h
+++ b/lldb/include/lldb/Target/RemoteAwarePlatform.h
@@ -58,8 +58,8 @@ class RemoteAwarePlatform : public Platform {
Status SetFilePermissions(const FileSpec _spec,
uint32_t file_permissions) override;
- bool CalculateMD5(const FileSpec _spec, uint64_t ,
-uint64_t ) override;
+ llvm::ErrorOr
+ CalculateMD5(const FileSpec _spec) override;
Status GetFileWithUUID(const FileSpec _file, const UUID *uuid,
FileSpec _file) override;
diff --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwinDevice.cpp
b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwinDevice.cpp
index 52777909a1f82..82156aca8cf15 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwinDevice.cpp
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwinDevice.cpp
@@ -405,17 +405,21 @@ lldb_private::Status
PlatformDarwinDevice::GetSharedModuleWithLocalCache(
// when going over the *slow* GDB remote transfer mechanism we first
// check the hashes of the files - and only do the actual transfer if
// they
diff er
- uint64_t high_local, high_remote, low_local, low_remote;
auto MD5 = llvm::sys::fs::md5_contents(module_cache_spec.GetPath());
if (!MD5)
return Status(MD5.getError());
- std::tie(high_local, low_local) = MD5->words();
-
[Lldb-commits] [lldb] [lldb] Unify CalculateMD5 return types (PR #91029)
Awfa wrote: > > @JDevlieghere , do you know if there's a way to run buildbot on a merge of > > this PR and main branch - just to validate the build/tests work before this > > merge? > > Not that I know. When failures are macOS specific I'm happy to apply a PR > locally and run the test suite and other folks with specific configurations > might do the same, but that's about all I can think of. > > > The [llvm contributing > > guide](https://llvm.org/docs/MyFirstTypoFix.html#myfirsttypofix-issues-after-landing-your-pr) > > says this is normal workflow - but I worry since I am using a lot of the > > maintainers' time to merge / revert the changes for me since I don't have > > write access. > > No worries, it's totally normal and we're happy to help with that! Can I ask you merge this for me? Hopefully no reverts this time :) https://github.com/llvm/llvm-project/pull/91029 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)
@@ -237,6 +250,16 @@ class ProcessInstanceInfo : public ProcessInfo {
m_cumulative_system_time.tv_usec > 0;
}
+ int8_t GetNiceValue() const { return m_nice_value; }
feg208 wrote:
prpsinfo has pr_nice field to be populated
https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/Process/elf-core/ThreadElfCore.h#L99
https://github.com/llvm/llvm-project/pull/91544
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/aarch64] Fix unwinding when signal interrupts a leaf function (PR #91321)
jasonmolenda wrote: Ah, so the problem is, ``` (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=1, subcode=0xdead) * frame #0: 0x00013f2c b.out`signal_generating_add + 4 at signal-in-leaf-function-aarch64.c:5 frame #1: 0x00013f7c b.out`main + 44 at signal-in-leaf-function-aarch64.c:14 frame #2: 0x000185c76244 dyld`start + 2792 ``` The bad instruction in `signal_generating_add()`, is sent to the program master a EXC_BAD_INSTRUCTION mach exception, not a posix signal (or maybe it was received by lldb as a mach exception and if it had continued to the process it would be recieved as a signal). When I've done these kinds of test cases in the past, I usually add a signal handler and then send the signal to the inferior, e.g. `lldb/test/API/functionalities/unwind/sigtramp/main.c` -- this test is marked `@skipUnlessDarwin` with a comment of ``` # On different platforms the "_sigtramp" and "__kill" frames are likely to be different. # This test could probably be adapted to run on linux/*bsd easily enough. ``` (the test explicitly checks the stack for the function names that should appear above the signal handler) 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
[Lldb-commits] [lldb] [lldb] Fixed SyntaxWarning: invalid escape sequence \[ \d \s (PR #91146)
https://github.com/slydiman closed https://github.com/llvm/llvm-project/pull/91146 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] ba66dfb - [lldb] Fixed SyntaxWarning: invalid escape sequence \[ \d \s (#91146)
Author: Dmitry Vasilyev
Date: 2024-05-10T01:56:14+04:00
New Revision: ba66dfb11bcaef5e0dc21358b3712b491d61d020
URL:
https://github.com/llvm/llvm-project/commit/ba66dfb11bcaef5e0dc21358b3712b491d61d020
DIFF:
https://github.com/llvm/llvm-project/commit/ba66dfb11bcaef5e0dc21358b3712b491d61d020.diff
LOG: [lldb] Fixed SyntaxWarning: invalid escape sequence \[ \d \s (#91146)
Reproduced with Python 3.12.3
Added:
Modified:
lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
Removed:
diff --git
a/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
index 75522158b3221..8c8e4abed0b45 100644
---
a/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
+++
b/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
@@ -130,9 +130,9 @@ def setUp(self):
self.stub_sends_two_stop_notifications_on_kill = False
if configuration.lldb_platform_url:
if configuration.lldb_platform_url.startswith("unix-"):
-url_pattern = "(.+)://\[?(.+?)\]?/.*"
+url_pattern = r"(.+)://\[?(.+?)\]?/.*"
else:
-url_pattern = "(.+)://(.+):\d+"
+url_pattern = r"(.+)://(.+):\d+"
scheme, host = re.match(
url_pattern, configuration.lldb_platform_url
).groups()
diff --git
a/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
index 61c5c3a7c865a..d1a4119bac781 100644
---
a/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
+++
b/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
@@ -50,7 +50,7 @@ def get_debugserver_exe():
_LOG_LINE_REGEX = re.compile(
-r"^(lldb-server|debugserver)\s+<\s*(\d+)>" +
"\s+(read|send)\s+packet:\s+(.+)$"
+r"^(lldb-server|debugserver)\s+<\s*(\d+)>\s+(read|send)\s+packet:\s+(.+)$"
)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] db94213 - [lldb/crashlog] Fix test failure when creating a target using command options (#91653)
Author: Med Ismail Bennani Date: 2024-05-09T14:13:44-07:00 New Revision: db9421381980cdf3d6914f8898a77d3237325019 URL: https://github.com/llvm/llvm-project/commit/db9421381980cdf3d6914f8898a77d3237325019 DIFF: https://github.com/llvm/llvm-project/commit/db9421381980cdf3d6914f8898a77d3237325019.diff LOG: [lldb/crashlog] Fix test failure when creating a target using command options (#91653) This should fix the various crashlog test failures on the bots: ``` lldb-shell :: ScriptInterpreter/Python/Crashlog/app_specific_backtrace_crashlog.test lldb-shell :: ScriptInterpreter/Python/Crashlog/interactive_crashlog_json.test lldb-shell :: ScriptInterpreter/Python/Crashlog/interactive_crashlog_legacy.test lldb-shell :: ScriptInterpreter/Python/Crashlog/last_exception_backtrace_crashlog.test lldb-shell :: ScriptInterpreter/Python/Crashlog/skipped_status_interactive_crashlog.test ``` When we create a target by using the command option, we don't set it in the crashlog object which later on cause us to fail loading the images. rdar://127832961 Signed-off-by: Med Ismail Bennani Added: Modified: lldb/examples/python/crashlog.py Removed: diff --git a/lldb/examples/python/crashlog.py b/lldb/examples/python/crashlog.py index 2919b9c76e68..641b2e64d53b 100755 --- a/lldb/examples/python/crashlog.py +++ b/lldb/examples/python/crashlog.py @@ -1494,6 +1494,7 @@ def load_crashlog_in_scripted_process(debugger, crashlog_path, options, result): raise InteractiveCrashLogException( "couldn't create target provided by the user (%s)" % options.target_path ) +crashlog.target = target # 2. If the user didn't provide a target, try to create a target using the symbolicator if not target or not target.IsValid(): ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix test failure when creating a target using command options (PR #91653)
https://github.com/medismailben closed https://github.com/llvm/llvm-project/pull/91653 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix test failure when creating a target using command options (PR #91653)
https://github.com/bulbazord approved this pull request. https://github.com/llvm/llvm-project/pull/91653 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix test failure when creating a target using command options (PR #91653)
https://github.com/JDevlieghere approved this pull request. https://github.com/llvm/llvm-project/pull/91653 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix test failure when creating a target using command options (PR #91653)
llvmbot wrote: @llvm/pr-subscribers-lldb Author: Med Ismail Bennani (medismailben) Changes This should fix the various crashlog test failures on the bots: ``` lldb-shell :: ScriptInterpreter/Python/Crashlog/app_specific_backtrace_crashlog.test lldb-shell :: ScriptInterpreter/Python/Crashlog/interactive_crashlog_json.test lldb-shell :: ScriptInterpreter/Python/Crashlog/interactive_crashlog_legacy.test lldb-shell :: ScriptInterpreter/Python/Crashlog/last_exception_backtrace_crashlog.test lldb-shell :: ScriptInterpreter/Python/Crashlog/skipped_status_interactive_crashlog.test ``` When we create a target by using the command option, we don't set it in the crashlog object which later on cause us to fail loading the images. rdar://127832961 --- Full diff: https://github.com/llvm/llvm-project/pull/91653.diff 1 Files Affected: - (modified) lldb/examples/python/crashlog.py (+1) ``diff diff --git a/lldb/examples/python/crashlog.py b/lldb/examples/python/crashlog.py index 2919b9c76e68b..641b2e64d53b1 100755 --- a/lldb/examples/python/crashlog.py +++ b/lldb/examples/python/crashlog.py @@ -1494,6 +1494,7 @@ def load_crashlog_in_scripted_process(debugger, crashlog_path, options, result): raise InteractiveCrashLogException( "couldn't create target provided by the user (%s)" % options.target_path ) +crashlog.target = target # 2. If the user didn't provide a target, try to create a target using the symbolicator if not target or not target.IsValid(): `` https://github.com/llvm/llvm-project/pull/91653 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix test failure when creating a target using command options (PR #91653)
https://github.com/medismailben created https://github.com/llvm/llvm-project/pull/91653 This should fix the various crashlog test failures on the bots: ``` lldb-shell :: ScriptInterpreter/Python/Crashlog/app_specific_backtrace_crashlog.test lldb-shell :: ScriptInterpreter/Python/Crashlog/interactive_crashlog_json.test lldb-shell :: ScriptInterpreter/Python/Crashlog/interactive_crashlog_legacy.test lldb-shell :: ScriptInterpreter/Python/Crashlog/last_exception_backtrace_crashlog.test lldb-shell :: ScriptInterpreter/Python/Crashlog/skipped_status_interactive_crashlog.test ``` When we create a target by using the command option, we don't set it in the crashlog object which later on cause us to fail loading the images. rdar://127832961 >From 3db7471fc507a1d5158d02f88402c846a8d4b4f3 Mon Sep 17 00:00:00 2001 From: Med Ismail Bennani Date: Thu, 9 May 2024 13:42:55 -0700 Subject: [PATCH] [lldb/crashlog] Fix test failure when creating a target using command options This should fix the various crashlog test failures. When we create a target by using the command option, we don't set it in the crashlog object which later on cause us to fail loading the images. rdar://127832961 Signed-off-by: Med Ismail Bennani --- lldb/examples/python/crashlog.py | 1 + 1 file changed, 1 insertion(+) diff --git a/lldb/examples/python/crashlog.py b/lldb/examples/python/crashlog.py index 2919b9c76e68..641b2e64d53b 100755 --- a/lldb/examples/python/crashlog.py +++ b/lldb/examples/python/crashlog.py @@ -1494,6 +1494,7 @@ def load_crashlog_in_scripted_process(debugger, crashlog_path, options, result): raise InteractiveCrashLogException( "couldn't create target provided by the user (%s)" % options.target_path ) +crashlog.target = target # 2. If the user didn't provide a target, try to create a target using the symbolicator if not target or not target.IsValid(): ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 639a740 - [AArch64] move extension information into tablgen (#90987)
Author: Tomas Matheson
Date: 2024-05-09T21:54:48+01:00
New Revision: 639a740035b732e9bc0f43f3f95d1ce3acf82e1b
URL:
https://github.com/llvm/llvm-project/commit/639a740035b732e9bc0f43f3f95d1ce3acf82e1b
DIFF:
https://github.com/llvm/llvm-project/commit/639a740035b732e9bc0f43f3f95d1ce3acf82e1b.diff
LOG: [AArch64] move extension information into tablgen (#90987)
Generate TargetParser extension information from tablegen. This includes FMV
extension information. FMV only extensions are represented by a separate
tablegen class.
Use MArchName/ArchKindEnumSpelling to avoid renamings.
Cases where there is simply a case difference are handled by
consistently uppercasing the AEK_ name in the emitted code.
Remove some Extensions which were not needed.
These had AEK entries but were never actually used for anything.
They are not present in Extensions[] data.
Added:
Modified:
clang/test/Driver/aarch64-implied-sme-features.c
clang/test/Driver/aarch64-implied-sve-features.c
lldb/test/Shell/Commands/command-disassemble-aarch64-extensions.s
llvm/include/llvm/TargetParser/AArch64TargetParser.h
llvm/lib/Target/AArch64/AArch64Features.td
llvm/unittests/TargetParser/TargetParserTest.cpp
llvm/utils/TableGen/ARMTargetDefEmitter.cpp
Removed:
diff --git a/clang/test/Driver/aarch64-implied-sme-features.c
b/clang/test/Driver/aarch64-implied-sme-features.c
index 67836f42f2c02..eca62e2563b78 100644
--- a/clang/test/Driver/aarch64-implied-sme-features.c
+++ b/clang/test/Driver/aarch64-implied-sme-features.c
@@ -14,7 +14,7 @@
// SME-CONFLICT: "-target-feature" "-bf16"{{.*}} "-target-feature" "-sme"
// RUN: %clang -target aarch64-linux-gnu -march=armv8-a+sme-i16i64 %s -###
2>&1 | FileCheck %s --check-prefix=SME-I16I64
-// SME-I16I64: "-target-feature" "+bf16"{{.*}} "-target-feature" "+sme-i16i64"
"-target-feature" "+sme"
+// SME-I16I64: "-target-feature" "+bf16"{{.*}} "-target-feature" "+sme"
"-target-feature" "+sme-i16i64"
// RUN: %clang -target aarch64-linux-gnu -march=armv8-a+nosme-i16i64 %s -###
2>&1 | FileCheck %s --check-prefix=NOSME-I16I64
// NOSME-I16I64-NOT: "-target-feature" "+sme-i16i64"
@@ -23,7 +23,7 @@
// NOSME-I16I64-NOT: sme-i16i64"
// RUN: %clang -target aarch64-linux-gnu
-march=armv8-a+sme-i16i64+nosme-i16i64 %s -### 2>&1 | FileCheck %s
--check-prefix=SME-I16I64-REVERT
-// SME-I16I64-REVERT: "-target-feature" "+bf16"{{.*}} "-target-feature"
"-sme-i16i64" "-target-feature" "+sme"
+// SME-I16I64-REVERT: "-target-feature" "+bf16"{{.*}} "-target-feature" "+sme"
"-target-feature" "-sme-i16i64"
// RUN: %clang -target aarch64-linux-gnu -march=armv8-a+nosme-f64f64 %s -###
2>&1 | FileCheck %s --check-prefix=NOSME-F64F64
// NOSME-F64F64-NOT: "-target-feature" "+sme-f64f64"
@@ -32,15 +32,15 @@
// NOSME-F64F64-NOT: sme-f64f64"
// RUN: %clang -target aarch64-linux-gnu
-march=armv8-a+sme-f64f64+nosme-f64f64 %s -### 2>&1 | FileCheck %s
--check-prefix=SME-F64F64-REVERT
-// SME-F64F64-REVERT: "-target-feature" "+bf16"{{.*}} "-target-feature"
"-sme-f64f64" "-target-feature" "+sme"
+// SME-F64F64-REVERT: "-target-feature" "+bf16"{{.*}} "-target-feature" "+sme"
"-target-feature" "-sme-f64f64"
// RUN: %clang -target aarch64-linux-gnu
-march=armv8-a+sme-f64f64+nosme-i16i64 %s -### 2>&1 | FileCheck %s
--check-prefix=SME-SUBFEATURE-MIX
// SME-SUBFEATURE-MIX-NOT: "+sme-i16i64"
-// SME-SUBFEATURE-MIX: "-target-feature" "+bf16"{{.*}} "-target-feature"
"+sme-f64f64" "-target-feature" "+sme"
+// SME-SUBFEATURE-MIX: "-target-feature" "+bf16"{{.*}} "-target-feature"
"+sme" "-target-feature" "+sme-f64f64"
// SME-SUBFEATURE-MIX-NOT: "+sme-i16i64"
// RUN: %clang -target aarch64-linux-gnu -march=armv8-a+sme-i16i64+nosme %s
-### 2>&1 | FileCheck %s --check-prefix=SME-SUBFEATURE-CONFLICT1
-// SME-SUBFEATURE-CONFLICT1: "-target-feature" "+bf16"{{.*}} "-target-feature"
"-sme-i16i64" "-target-feature" "-sme"
+// SME-SUBFEATURE-CONFLICT1: "-target-feature" "+bf16"{{.*}} "-target-feature"
"-sme" "-target-feature" "-sme-i16i64"
// RUN: %clang -target aarch64-linux-gnu -march=armv8-a+sme-f64f64+nobf16 %s
-### 2>&1 | FileCheck %s --check-prefix=SME-SUBFEATURE-CONFLICT2
// SME-SUBFEATURE-CONFLICT2-NOT: "-target-feature" "+bf16"
@@ -48,4 +48,4 @@
// SME-SUBFEATURE-CONFLICT2-NOT: "-target-feature" "+sme-f64f64"
// RUN: %clang -target aarch64-linux-gnu -march=armv8-a+nosme+sme-i16i64 %s
-### 2>&1 | FileCheck %s --check-prefix=SME-SUBFEATURE-CONFLICT-REV
-// SME-SUBFEATURE-CONFLICT-REV: "-target-feature" "+bf16"{{.*}}
"-target-feature" "+sme-i16i64" "-target-feature" "+sme"
+// SME-SUBFEATURE-CONFLICT-REV: "-target-feature" "+bf16"{{.*}}
"-target-feature" "+sme" "-target-feature" "+sme-i16i64"
diff --git a/clang/test/Driver/aarch64-implied-sve-features.c
b/clang/test/Driver/aarch64-implied-sve-features.c
index 9227cd4981c2e..f04e1a785673b 100644
---
[Lldb-commits] [clang] [lldb] [llvm] [AArch64] move extension information into tablgen (PR #90987)
https://github.com/tmatheson-arm closed https://github.com/llvm/llvm-project/pull/90987 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
https://github.com/medismailben closed https://github.com/llvm/llvm-project/pull/91631 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] f4a7e1f - [lldb/crashlog] Fix module binary resolution (#91631)
Author: Med Ismail Bennani
Date: 2024-05-09T13:51:52-07:00
New Revision: f4a7e1f9bac1f11e1db1c0a895f3f681838f89f2
URL:
https://github.com/llvm/llvm-project/commit/f4a7e1f9bac1f11e1db1c0a895f3f681838f89f2
DIFF:
https://github.com/llvm/llvm-project/commit/f4a7e1f9bac1f11e1db1c0a895f3f681838f89f2.diff
LOG: [lldb/crashlog] Fix module binary resolution (#91631)
This patch fixes a bug in when resolving and loading modules from the
binary image list.
When loading a module, we would first use the UUID from the binary image
list with `dsymForUUID` to fetch the dSYM bundle from our remote build
records and copy the executable locally.
If we failed to find a matching dSYM bundle for that UUID on the build
record, let's say if that module was built locally, we use Spotlight
(`mdfind`) to find the dSYM bundle once again using the UUID.
Prior to this patch, we would set the image path to be the same as the
symbol file. This resulted in trying to load the dSYM as a module in
lldb, which isn't allowed.
This patch address that by looking for a binary matching the image
identifier, next to the dSYM bundle and try to load that instead.
rdar://127433616
Signed-off-by: Med Ismail Bennani
Added:
Modified:
lldb/examples/python/crashlog.py
Removed:
diff --git a/lldb/examples/python/crashlog.py
b/lldb/examples/python/crashlog.py
index eb9af6ed3d95..2919b9c76e68 100755
--- a/lldb/examples/python/crashlog.py
+++ b/lldb/examples/python/crashlog.py
@@ -418,9 +418,20 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+executables = []
+for root, _, files in os.walk(parent_dir):
+for file in files:
+abs_path = os.path.join(root, file)
+if os.path.isfile(abs_path) and os.access(
+abs_path, os.X_OK
+):
+executables.append(abs_path)
+for binary in executables:
+basename = os.path.basename(binary)
+if basename == self.identifier:
+self.path = binary
found_matching_slice = True
break
if found_matching_slice:
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
https://github.com/bulbazord approved this pull request. https://github.com/llvm/llvm-project/pull/91631 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
https://github.com/medismailben updated
https://github.com/llvm/llvm-project/pull/91631
>From 1f63d6807bc8a6b1e04cb96cbc7e4fd1572553e4 Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani
Date: Thu, 9 May 2024 12:51:39 -0700
Subject: [PATCH] [lldb/crashlog] Fix module binary resolution
This patch fixes a bug in when resolving and loading modules from the
binary image list.
When loading a module, we would first use the UUID from the binary image
list with `dsymForUUID` to fetch the dSYM bundle from our remote build
records and copy the executable locally.
If we failed to find a matching dSYM bundle for that UUID on the build
record, let's say if that module was built locally, we use Spotlight
(`mdfind`) to find the dSYM bundle once again using the UUID.
Prior to this patch, we would set the image path to be the same as the
symbol file. This resulted in trying to load the dSYM as a module in
lldb, which isn't allowed.
This patch address that by looking for a binary matching the image
identifier, next to the dSYM bundle and try to load that instead.
rdar://127433616
Signed-off-by: Med Ismail Bennani
---
lldb/examples/python/crashlog.py | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/lldb/examples/python/crashlog.py b/lldb/examples/python/crashlog.py
index eb9af6ed3d95..2919b9c76e68 100755
--- a/lldb/examples/python/crashlog.py
+++ b/lldb/examples/python/crashlog.py
@@ -418,9 +418,20 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+executables = []
+for root, _, files in os.walk(parent_dir):
+for file in files:
+abs_path = os.path.join(root, file)
+if os.path.isfile(abs_path) and os.access(
+abs_path, os.X_OK
+):
+executables.append(abs_path)
+for binary in executables:
+basename = os.path.basename(binary)
+if basename == self.identifier:
+self.path = binary
found_matching_slice = True
break
if found_matching_slice:
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
@@ -418,9 +418,20 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+executables = []
+for root, dirs, files in os.walk(parent_dir):
+for file in files:
+abs_path = os.path.join(root, file)
+if os.path.isfile(abs_path) and os.access(
medismailben wrote:
It could be block device or another file type fwiw.
https://github.com/llvm/llvm-project/pull/91631
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
@@ -418,9 +418,20 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+executables = []
+for root, dirs, files in os.walk(parent_dir):
JDevlieghere wrote:
Let's use `_` instead of `dirs` as it's unused.
https://github.com/llvm/llvm-project/pull/91631
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
https://github.com/JDevlieghere edited https://github.com/llvm/llvm-project/pull/91631 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
https://github.com/JDevlieghere approved this pull request. https://github.com/llvm/llvm-project/pull/91631 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
@@ -418,9 +418,20 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+executables = []
+for root, dirs, files in os.walk(parent_dir):
+for file in files:
+abs_path = os.path.join(root, file)
+if os.path.isfile(abs_path) and os.access(
bulbazord wrote:
This must necessarily be a file right? It's in the `files` output of `os.walk`.
Could it be something else?
https://github.com/llvm/llvm-project/pull/91631
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][breakpoint] Grey out disabled breakpoints (PR #91404)
@@ -848,6 +850,13 @@ void Breakpoint::GetDescription(Stream *s,
lldb::DescriptionLevel level,
const size_t num_locations = GetNumLocations();
const size_t num_resolved_locations = GetNumResolvedLocations();
+ // Grey out any disabled breakpoints in the list of breakpoints.
+ if (GetTarget().GetDebugger().GetUseColor())
+s->Printf("%s",
+ IsEnabled()
+ ? ansi::FormatAnsiTerminalCodes("${ansi.normal}").c_str()
+ : ansi::FormatAnsiTerminalCodes("${ansi.faint}").c_str());
chelcassanova wrote:
I also thought that I'd have to reset the colours back to normal somewhere but
when I tried this for a little the colours seemed fine without explicitly
placing a reset somewhere.
I can still add a reset alongside this simplified logic though.
https://github.com/llvm/llvm-project/pull/91404
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
https://github.com/medismailben updated
https://github.com/llvm/llvm-project/pull/91631
>From b849720f6559392f91c54be5987beeb8c8c3fe21 Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani
Date: Thu, 9 May 2024 12:39:01 -0700
Subject: [PATCH] [lldb/crashlog] Fix module binary resolution
This patch fixes a bug in when resolving and loading modules from the
binary image list.
When loading a module, we would first use the UUID from the binary image
list with `dsymForUUID` to fetch the dSYM bundle from our remote build
records and copy the executable locally.
If we failed to find a matching dSYM bundle for that UUID on the build
record, let's say if that module was built locally, we use Spotlight
(`mdfind`) to find the dSYM bundle once again using the UUID.
Prior to this patch, we would set the image path to be the same as the
symbol file. This resulted in trying to load the dSYM as a module in
lldb, which isn't allowed.
This patch address that by looking for a binary matching the image
identifier, next to the dSYM bundle and try to load that instead.
rdar://127433616
Signed-off-by: Med Ismail Bennani
---
lldb/examples/python/crashlog.py | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/lldb/examples/python/crashlog.py b/lldb/examples/python/crashlog.py
index eb9af6ed3d95c..124351f4d754b 100755
--- a/lldb/examples/python/crashlog.py
+++ b/lldb/examples/python/crashlog.py
@@ -418,9 +418,20 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+executables = []
+for root, dirs, files in os.walk(parent_dir):
+for file in files:
+abs_path = os.path.join(root, file)
+if os.path.isfile(abs_path) and os.access(
+abs_path, os.X_OK
+):
+executables.append(abs_path)
+for binary in executables:
+basename = os.path.basename(binary)
+if basename == self.identifier:
+self.path = binary
found_matching_slice = True
break
if found_matching_slice:
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][breakpoint] Grey out disabled breakpoints (PR #91404)
@@ -848,6 +850,13 @@ void Breakpoint::GetDescription(Stream *s,
lldb::DescriptionLevel level,
const size_t num_locations = GetNumLocations();
const size_t num_resolved_locations = GetNumResolvedLocations();
+ // Grey out any disabled breakpoints in the list of breakpoints.
+ if (GetTarget().GetDebugger().GetUseColor())
+s->Printf("%s",
+ IsEnabled()
+ ? ansi::FormatAnsiTerminalCodes("${ansi.normal}").c_str()
+ : ansi::FormatAnsiTerminalCodes("${ansi.faint}").c_str());
JDevlieghere wrote:
You need to reset the color after printing, otherwise everything in the
terminal printed after will be faint. Also seems like you can simplify this by
moving the check for `IsEnabled()` into the first `if`:
```
const bool print_faint = !IsEnabled() &&
GetTarget().GetDebugger().GetUseColor();
if (print_faint)
s->Print(ansi::FormatAnsiTerminalCodes("${ansi.faint}"));
[...]
if (print_faint)
s->Print(ansi::FormatAnsiTerminalCodes("${ansi.reset}"));
```
https://github.com/llvm/llvm-project/pull/91404
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
https://github.com/medismailben updated
https://github.com/llvm/llvm-project/pull/91631
>From e2cd9670c20daac3f6a5f75806c7f48ed7b2ccd9 Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani
Date: Thu, 9 May 2024 11:38:03 -0700
Subject: [PATCH] [lldb/crashlog] Fix module binary resolution
This patch fixes a bug in when resolving and loading modules from the
binary image list.
When loading a module, we would first use the UUID from the binary image
list with `dsymForUUID` to fetch the dSYM bundle from our remote build
records and copy the executable locally.
If we failed to find a matching dSYM bundle for that UUID on the build
record, let's say if that module was built locally, we use Spotlight
(`mdfind`) to find the dSYM bundle once again using the UUID.
Prior to this patch, we would set the image path to be the same as the
symbol file. This resulted in trying to load the dSYM as a module in
lldb, which isn't allowed.
This patch address that by looking for a binary matching the image
identifier, next to the dSYM bundle and try to load that instead.
rdar://127433616
Signed-off-by: Med Ismail Bennani
---
lldb/examples/python/crashlog.py | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/lldb/examples/python/crashlog.py b/lldb/examples/python/crashlog.py
index eb9af6ed3d95..4e79c718c9ea 100755
--- a/lldb/examples/python/crashlog.py
+++ b/lldb/examples/python/crashlog.py
@@ -418,9 +418,20 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+executables = []
+for root, dirs, files in os.walk(os.getcwd()):
+for file in files:
+abs_path = os.path.join(root, file)
+if os.path.isfile(abs_path) and os.access(
+abs_path, os.X_OK
+):
+executables.append(abs_path)
+for binary in executables:
+basename = os.path.basename(binary)
+if os.path.exists(abs_path) and basename ==
self.identifier:
+self.path = abs_path
found_matching_slice = True
break
if found_matching_slice:
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][breakpoint] Grey out disabled breakpoints (PR #91404)
https://github.com/chelcassanova edited https://github.com/llvm/llvm-project/pull/91404 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][breakpoint] Grey out disabled breakpoints (PR #91404)
https://github.com/chelcassanova edited https://github.com/llvm/llvm-project/pull/91404 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][breakpointoptions] Make disabled keyword red (PR #91404)
chelcassanova wrote: I changed this PR to make disabled breakpoints greyed out (per Ismail's suggestion). Since this is being done at the `Breakpoint` level we have access to the target and its debugger to access `GetUseColor()`. https://github.com/llvm/llvm-project/pull/91404 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][breakpointoptions] Make disabled keyword red (PR #91404)
https://github.com/chelcassanova updated
https://github.com/llvm/llvm-project/pull/91404
>From c334f7357aebefa3e0b7af645396e699cf3a4c8d Mon Sep 17 00:00:00 2001
From: Chelsea Cassanova
Date: Thu, 9 May 2024 11:08:29 -0700
Subject: [PATCH] [lldb][breakpoint] Grey out disabled breakpoints
This commit adds colour settings to the list of breakpoints in order to
grey out breakpoints that have been disabled.
---
lldb/source/Breakpoint/Breakpoint.cpp | 9 +
1 file changed, 9 insertions(+)
diff --git a/lldb/source/Breakpoint/Breakpoint.cpp
b/lldb/source/Breakpoint/Breakpoint.cpp
index ae845e92762b9..3f42e9fc7df90 100644
--- a/lldb/source/Breakpoint/Breakpoint.cpp
+++ b/lldb/source/Breakpoint/Breakpoint.cpp
@@ -15,6 +15,7 @@
#include "lldb/Breakpoint/BreakpointResolver.h"
#include "lldb/Breakpoint/BreakpointResolverFileLine.h"
#include "lldb/Core/Address.h"
+#include "lldb/Core/Debugger.h"
#include "lldb/Core/Module.h"
#include "lldb/Core/ModuleList.h"
#include "lldb/Core/SearchFilter.h"
@@ -26,6 +27,7 @@
#include "lldb/Target/SectionLoadList.h"
#include "lldb/Target/Target.h"
#include "lldb/Target/ThreadSpec.h"
+#include "lldb/Utility/AnsiTerminal.h"
#include "lldb/Utility/LLDBLog.h"
#include "lldb/Utility/Log.h"
#include "lldb/Utility/Stream.h"
@@ -848,6 +850,13 @@ void Breakpoint::GetDescription(Stream *s,
lldb::DescriptionLevel level,
const size_t num_locations = GetNumLocations();
const size_t num_resolved_locations = GetNumResolvedLocations();
+ // Grey out any disabled breakpoints in the list of breakpoints.
+ if (GetTarget().GetDebugger().GetUseColor())
+s->Printf("%s",
+ IsEnabled()
+ ? ansi::FormatAnsiTerminalCodes("${ansi.normal}").c_str()
+ : ansi::FormatAnsiTerminalCodes("${ansi.faint}").c_str());
+
// They just made the breakpoint, they don't need to be told HOW they made
// it... Also, we'll print the breakpoint number differently depending on
// whether there is 1 or more locations.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
@@ -418,9 +418,22 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+find_results = (
+subprocess.check_output(
+'/usr/bin/find "%s" -type f \( -perm -u=x -o
-perm -g=x -o -perm -o=x \)'
+% parent_dir,
+shell=True,
+)
+.decode("utf-8")
+.splitlines()
+)
+for binary in find_results:
+abs_path = os.path.abspath(binary)
+basename = os.path.basename(binary)
+if os.path.exists(abs_path) and basename ==
self.identifier:
bulbazord wrote:
Do we expect `abs_path` to not exist after the call to `find`?
https://github.com/llvm/llvm-project/pull/91631
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
@@ -418,9 +418,22 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+find_results = (
+subprocess.check_output(
+'/usr/bin/find "%s" -type f \( -perm -u=x -o
-perm -g=x -o -perm -o=x \)'
JDevlieghere wrote:
Rather than shelling out to find, can you use `os.walk`?
https://github.com/llvm/llvm-project/pull/91631
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Med Ismail Bennani (medismailben)
Changes
This patch fixes a bug in when resolving and loading modules from the binary
image list.
When loading a module, we would first use the UUID from the binary image list
with `dsymForUUID` to fetch the dSYM bundle from our remote build records and
copy the executable locally.
If we failed to find a matching dSYM bundle for that UUID on the build record,
let's say if that module was built locally, we use Spotlight (`mdfind`) to find
the dSYM bundle once again using the UUID.
Prior to this patch, we would set the image path to be the same as the symbol
file. This resulted in trying to load the dSYM as a module in lldb, which isn't
allowed.
This patch address that by looking for a binary matching the image identifier,
next to the dSYM bundle and try to load that instead.
rdar://127433616
---
Full diff: https://github.com/llvm/llvm-project/pull/91631.diff
1 Files Affected:
- (modified) lldb/examples/python/crashlog.py (+16-3)
``diff
diff --git a/lldb/examples/python/crashlog.py b/lldb/examples/python/crashlog.py
index eb9af6ed3d95..3e3fa1d6ed3c 100755
--- a/lldb/examples/python/crashlog.py
+++ b/lldb/examples/python/crashlog.py
@@ -418,9 +418,22 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+find_results = (
+subprocess.check_output(
+'/usr/bin/find "%s" -type f \( -perm -u=x -o
-perm -g=x -o -perm -o=x \)'
+% parent_dir,
+shell=True,
+)
+.decode("utf-8")
+.splitlines()
+)
+for binary in find_results:
+abs_path = os.path.abspath(binary)
+basename = os.path.basename(binary)
+if os.path.exists(abs_path) and basename ==
self.identifier:
+self.path = abs_path
found_matching_slice = True
break
if found_matching_slice:
``
https://github.com/llvm/llvm-project/pull/91631
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Fix module binary resolution (PR #91631)
https://github.com/medismailben created
https://github.com/llvm/llvm-project/pull/91631
This patch fixes a bug in when resolving and loading modules from the binary
image list.
When loading a module, we would first use the UUID from the binary image list
with `dsymForUUID` to fetch the dSYM bundle from our remote build records and
copy the executable locally.
If we failed to find a matching dSYM bundle for that UUID on the build record,
let's say if that module was built locally, we use Spotlight (`mdfind`) to find
the dSYM bundle once again using the UUID.
Prior to this patch, we would set the image path to be the same as the symbol
file. This resulted in trying to load the dSYM as a module in lldb, which isn't
allowed.
This patch address that by looking for a binary matching the image identifier,
next to the dSYM bundle and try to load that instead.
rdar://127433616
>From 13497173bbcc1007bb1ad01820237b934c9a88f4 Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani
Date: Thu, 9 May 2024 09:52:38 -0700
Subject: [PATCH] [lldb/crashlog] Fix module binary resolution
This patch fixes a bug in when resolving and loading modules from the
binary image list.
When loading a module, we would first use the UUID from the binary image
list with `dsymForUUID` to fetch the dSYM bundle from our remote build
records and copy the executable locally.
If we failed to find a matching dSYM bundle for that UUID on the build
record, let's say if that module was built locally, we use Spotlight
(`mdfind`) to find the dSYM bundle once again using the UUID.
Prior to this patch, we would set the image path to be the same as the
symbol file. This resulted in trying to load the dSYM as a module in
lldb, which isn't allowed.
This patch address that by looking for a binary matching the image
identifier, next to the dSYM bundle and try to load that instead.
rdar://127433616
Signed-off-by: Med Ismail Bennani
---
lldb/examples/python/crashlog.py | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/lldb/examples/python/crashlog.py b/lldb/examples/python/crashlog.py
index eb9af6ed3d95c..3e3fa1d6ed3c7 100755
--- a/lldb/examples/python/crashlog.py
+++ b/lldb/examples/python/crashlog.py
@@ -418,9 +418,22 @@ def locate_module_and_debug_symbols(self):
with print_lock:
print('falling back to binary inside "%s"' % dsym)
self.symfile = dsym
-for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if self.find_matching_slice():
+# Look for the executable next to the dSYM bundle.
+parent_dir = os.path.dirname(dsym)
+find_results = (
+subprocess.check_output(
+'/usr/bin/find "%s" -type f \( -perm -u=x -o
-perm -g=x -o -perm -o=x \)'
+% parent_dir,
+shell=True,
+)
+.decode("utf-8")
+.splitlines()
+)
+for binary in find_results:
+abs_path = os.path.abspath(binary)
+basename = os.path.basename(binary)
+if os.path.exists(abs_path) and basename ==
self.identifier:
+self.path = abs_path
found_matching_slice = True
break
if found_matching_slice:
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Verify target stop-hooks support with scripted process (PR #91107)
https://github.com/medismailben closed https://github.com/llvm/llvm-project/pull/91107 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] b3a835e - [lldb] Verify target stop-hooks support with scripted process (#91107)
Author: Med Ismail Bennani
Date: 2024-05-09T10:39:05-07:00
New Revision: b3a835e129ed8a67cf393f9ee26989b36a3eff1c
URL:
https://github.com/llvm/llvm-project/commit/b3a835e129ed8a67cf393f9ee26989b36a3eff1c
DIFF:
https://github.com/llvm/llvm-project/commit/b3a835e129ed8a67cf393f9ee26989b36a3eff1c.diff
LOG: [lldb] Verify target stop-hooks support with scripted process (#91107)
This patch makes sure that scripted process are compatible with target
stop-hooks. This wasn't tested in the past, but it turned out to be
working out of the box.
rdar://124396534
Signed-off-by: Med Ismail Bennani
Added:
Modified:
lldb/test/API/functionalities/scripted_process/TestScriptedProcess.py
lldb/test/API/functionalities/scripted_process/dummy_scripted_process.py
Removed:
diff --git
a/lldb/test/API/functionalities/scripted_process/TestScriptedProcess.py
b/lldb/test/API/functionalities/scripted_process/TestScriptedProcess.py
index 5aaf68575623c..9519c576689d0 100644
--- a/lldb/test/API/functionalities/scripted_process/TestScriptedProcess.py
+++ b/lldb/test/API/functionalities/scripted_process/TestScriptedProcess.py
@@ -187,6 +187,10 @@ def cleanup():
+ os.path.join(self.getSourceDir(),
scripted_process_example_relpath)
)
+self.runCmd(
+"target stop-hook add -k first -v 1 -k second -v 2 -P
dummy_scripted_process.DummyStopHook"
+)
+
launch_info = lldb.SBLaunchInfo(None)
launch_info.SetProcessPluginName("ScriptedProcess")
launch_info.SetScriptedProcessClassName(
@@ -207,6 +211,9 @@ def cleanup():
self.assertTrue(hasattr(py_impl, "my_super_secret_member"))
self.assertEqual(py_impl.my_super_secret_method(), 42)
+self.assertTrue(hasattr(py_impl, "handled_stop"))
+self.assertTrue(py_impl.handled_stop)
+
# Try reading from target #0 process ...
addr = 0x5
message = "Hello, target 0"
diff --git
a/lldb/test/API/functionalities/scripted_process/dummy_scripted_process.py
b/lldb/test/API/functionalities/scripted_process/dummy_scripted_process.py
index 5aff3aa4bb559..cb07bf32c5080 100644
--- a/lldb/test/API/functionalities/scripted_process/dummy_scripted_process.py
+++ b/lldb/test/API/functionalities/scripted_process/dummy_scripted_process.py
@@ -7,6 +7,16 @@
from lldb.plugins.scripted_process import ScriptedThread
+class DummyStopHook:
+def __init__(self, target, args, internal_dict):
+self.target = target
+self.args = args
+
+def handle_stop(self, exe_ctx, stream):
+print("My DummyStopHook triggered. Printing args: \n%s" % self.args)
+sp = exe_ctx.process.GetScriptedImplementation()
+sp.handled_stop = True
+
class DummyScriptedProcess(ScriptedProcess):
memory = None
@@ -18,6 +28,7 @@ def __init__(self, exe_ctx: lldb.SBExecutionContext, args:
lldb.SBStructuredData
debugger = self.target.GetDebugger()
index = debugger.GetIndexOfTarget(self.target)
self.memory[addr] = "Hello, target " + str(index)
+self.handled_stop = False
def read_memory_at_address(
self, addr: int, size: int, error: lldb.SBError
@@ -99,7 +110,13 @@ def get_register_context(self) -> str:
def __lldb_init_module(debugger, dict):
+# This is used when loading the script in an interactive debug session to
+# automatically, register the stop-hook and launch the scripted process.
if not "SKIP_SCRIPTED_PROCESS_LAUNCH" in os.environ:
+debugger.HandleCommand(
+"target stop-hook add -k first -v 1 -k second -v 2 -P %s.%s"
+% (__name__, DummyStopHook.__name__)
+)
debugger.HandleCommand(
"process launch -C %s.%s" % (__name__,
DummyScriptedProcess.__name__)
)
@@ -108,3 +125,7 @@ def __lldb_init_module(debugger, dict):
"Name of the class that will manage the scripted process: '%s.%s'"
% (__name__, DummyScriptedProcess.__name__)
)
+print(
+"Name of the class that will manage the stop-hook: '%s.%s'"
+% (__name__, DummyStopHook.__name__)
+)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Verify target stop-hooks support with scripted process (PR #91107)
https://github.com/medismailben updated
https://github.com/llvm/llvm-project/pull/91107
>From d34abd53e2cd8484299516f8c7f01fe45e58e07c Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani
Date: Thu, 9 May 2024 10:35:33 -0700
Subject: [PATCH] [lldb] Verify target stop-hooks support with scripted process
This patch makes sure that scripted process are compatible with target
stop-hooks. This wasn't tested in the past, but it turned out to be
working out of the box.
rdar://124396534
Signed-off-by: Med Ismail Bennani
---
.../scripted_process/TestScriptedProcess.py | 7 +++
.../dummy_scripted_process.py | 21 +++
2 files changed, 28 insertions(+)
diff --git
a/lldb/test/API/functionalities/scripted_process/TestScriptedProcess.py
b/lldb/test/API/functionalities/scripted_process/TestScriptedProcess.py
index 5aaf68575623c..9519c576689d0 100644
--- a/lldb/test/API/functionalities/scripted_process/TestScriptedProcess.py
+++ b/lldb/test/API/functionalities/scripted_process/TestScriptedProcess.py
@@ -187,6 +187,10 @@ def cleanup():
+ os.path.join(self.getSourceDir(),
scripted_process_example_relpath)
)
+self.runCmd(
+"target stop-hook add -k first -v 1 -k second -v 2 -P
dummy_scripted_process.DummyStopHook"
+)
+
launch_info = lldb.SBLaunchInfo(None)
launch_info.SetProcessPluginName("ScriptedProcess")
launch_info.SetScriptedProcessClassName(
@@ -207,6 +211,9 @@ def cleanup():
self.assertTrue(hasattr(py_impl, "my_super_secret_member"))
self.assertEqual(py_impl.my_super_secret_method(), 42)
+self.assertTrue(hasattr(py_impl, "handled_stop"))
+self.assertTrue(py_impl.handled_stop)
+
# Try reading from target #0 process ...
addr = 0x5
message = "Hello, target 0"
diff --git
a/lldb/test/API/functionalities/scripted_process/dummy_scripted_process.py
b/lldb/test/API/functionalities/scripted_process/dummy_scripted_process.py
index 5aff3aa4bb559..cb07bf32c5080 100644
--- a/lldb/test/API/functionalities/scripted_process/dummy_scripted_process.py
+++ b/lldb/test/API/functionalities/scripted_process/dummy_scripted_process.py
@@ -7,6 +7,16 @@
from lldb.plugins.scripted_process import ScriptedThread
+class DummyStopHook:
+def __init__(self, target, args, internal_dict):
+self.target = target
+self.args = args
+
+def handle_stop(self, exe_ctx, stream):
+print("My DummyStopHook triggered. Printing args: \n%s" % self.args)
+sp = exe_ctx.process.GetScriptedImplementation()
+sp.handled_stop = True
+
class DummyScriptedProcess(ScriptedProcess):
memory = None
@@ -18,6 +28,7 @@ def __init__(self, exe_ctx: lldb.SBExecutionContext, args:
lldb.SBStructuredData
debugger = self.target.GetDebugger()
index = debugger.GetIndexOfTarget(self.target)
self.memory[addr] = "Hello, target " + str(index)
+self.handled_stop = False
def read_memory_at_address(
self, addr: int, size: int, error: lldb.SBError
@@ -99,7 +110,13 @@ def get_register_context(self) -> str:
def __lldb_init_module(debugger, dict):
+# This is used when loading the script in an interactive debug session to
+# automatically, register the stop-hook and launch the scripted process.
if not "SKIP_SCRIPTED_PROCESS_LAUNCH" in os.environ:
+debugger.HandleCommand(
+"target stop-hook add -k first -v 1 -k second -v 2 -P %s.%s"
+% (__name__, DummyStopHook.__name__)
+)
debugger.HandleCommand(
"process launch -C %s.%s" % (__name__,
DummyScriptedProcess.__name__)
)
@@ -108,3 +125,7 @@ def __lldb_init_module(debugger, dict):
"Name of the class that will manage the scripted process: '%s.%s'"
% (__name__, DummyScriptedProcess.__name__)
)
+print(
+"Name of the class that will manage the stop-hook: '%s.%s'"
+% (__name__, DummyStopHook.__name__)
+)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][enums] Remove broadcast bits from debugger (PR #91618)
https://github.com/chelcassanova closed https://github.com/llvm/llvm-project/pull/91618 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] b9e3fa8 - [lldb][enums] Remove broadcast bits from debugger (#91618)
Author: Chelsea Cassanova
Date: 2024-05-09T10:28:23-07:00
New Revision: b9e3fa84d3fdfe718a4a3085f7adeda3d81f2568
URL:
https://github.com/llvm/llvm-project/commit/b9e3fa84d3fdfe718a4a3085f7adeda3d81f2568
DIFF:
https://github.com/llvm/llvm-project/commit/b9e3fa84d3fdfe718a4a3085f7adeda3d81f2568.diff
LOG: [lldb][enums] Remove broadcast bits from debugger (#91618)
Removes the debugger broadcast bits from `Debugger.h` and instead uses
the enum from `lldb-enumerations.h` and adds the
`eBroadcastSymbolChange` bit to the enum in `lldb-enumerations.h`. This fixes a
bug wherein the incorrect broadcast bit could be referenced due both of these
enums previously existing and being out-of-sync with each other.
Added:
Modified:
lldb/include/lldb/Core/Debugger.h
lldb/include/lldb/lldb-enumerations.h
lldb/source/Core/Debugger.cpp
lldb/source/Core/Progress.cpp
lldb/unittests/Core/DiagnosticEventTest.cpp
lldb/unittests/Core/ProgressReportTest.cpp
Removed:
diff --git a/lldb/include/lldb/Core/Debugger.h
b/lldb/include/lldb/Core/Debugger.h
index c0f7c732ad2d4..ea994bf8c28dd 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -78,15 +78,6 @@ class Debugger : public
std::enable_shared_from_this,
public UserID,
public Properties {
public:
- /// Broadcaster event bits definitions.
- enum {
-eBroadcastBitProgress = (1 << 0),
-eBroadcastBitWarning = (1 << 1),
-eBroadcastBitError = (1 << 2),
-eBroadcastSymbolChange = (1 << 3),
-eBroadcastBitProgressCategory = (1 << 4),
- };
-
using DebuggerList = std::vector;
static llvm::StringRef GetStaticBroadcasterClass();
@@ -628,7 +619,7 @@ class Debugger : public
std::enable_shared_from_this,
ReportProgress(uint64_t progress_id, std::string title, std::string details,
uint64_t completed, uint64_t total,
std::optional debugger_id,
- uint32_t progress_category_bit = eBroadcastBitProgress);
+ uint32_t progress_category_bit = lldb::eBroadcastBitProgress);
static void ReportDiagnosticImpl(lldb::Severity severity, std::string
message,
std::optional debugger_id,
diff --git a/lldb/include/lldb/lldb-enumerations.h
b/lldb/include/lldb/lldb-enumerations.h
index 437971b3364cd..8e05f6ba9c876 100644
--- a/lldb/include/lldb/lldb-enumerations.h
+++ b/lldb/include/lldb/lldb-enumerations.h
@@ -1344,7 +1344,8 @@ enum DebuggerBroadcastBit {
eBroadcastBitProgress = (1 << 0),
eBroadcastBitWarning = (1 << 1),
eBroadcastBitError = (1 << 2),
- eBroadcastBitProgressCategory = (1 << 3),
+ eBroadcastSymbolChange = (1 << 3),
+ eBroadcastBitProgressCategory = (1 << 4),
};
/// Used for expressing severity in logs and diagnostics.
diff --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 976420a434439..9951fbcd3e7c3 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -1485,10 +1485,10 @@ static void PrivateReportDiagnostic(Debugger ,
Severity severity,
assert(false && "eSeverityInfo should not be broadcast");
return;
case eSeverityWarning:
-event_type = Debugger::eBroadcastBitWarning;
+event_type = lldb::eBroadcastBitWarning;
break;
case eSeverityError:
-event_type = Debugger::eBroadcastBitError;
+event_type = lldb::eBroadcastBitError;
break;
}
@@ -1572,7 +1572,7 @@ void Debugger::ReportSymbolChange(const ModuleSpec
_spec) {
std::lock_guard guard(*g_debugger_list_mutex_ptr);
for (DebuggerSP debugger_sp : *g_debugger_list_ptr) {
EventSP event_sp = std::make_shared(
- Debugger::eBroadcastSymbolChange,
+ lldb::eBroadcastSymbolChange,
new SymbolChangeEventData(debugger_sp, module_spec));
debugger_sp->GetBroadcaster().BroadcastEvent(event_sp);
}
@@ -1879,8 +1879,9 @@ lldb::thread_result_t Debugger::DefaultEventHandler() {
CommandInterpreter::eBroadcastBitAsynchronousErrorData);
listener_sp->StartListeningForEvents(
- _broadcaster, eBroadcastBitProgress | eBroadcastBitWarning |
- eBroadcastBitError | eBroadcastSymbolChange);
+ _broadcaster, lldb::eBroadcastBitProgress | lldb::eBroadcastBitWarning
|
+ lldb::eBroadcastBitError |
+ lldb::eBroadcastSymbolChange);
// Let the thread that spawned us know that we have started up and that we
// are now listening to all required events so no events get missed
@@ -1932,11 +1933,11 @@ lldb::thread_result_t Debugger::DefaultEventHandler() {
}
}
} else if (broadcaster == _broadcaster) {
-if (event_type & Debugger::eBroadcastBitProgress)
+if (event_type & lldb::eBroadcastBitProgress)
[Lldb-commits] [lldb] [lldb][enums] Remove broadcast bits from debugger (PR #91618)
https://github.com/chelcassanova updated
https://github.com/llvm/llvm-project/pull/91618
>From 167850e01960175e332b9da3d95d6054102a960a Mon Sep 17 00:00:00 2001
From: Chelsea Cassanova
Date: Thu, 9 May 2024 09:23:02 -0700
Subject: [PATCH] [lldb][enums] Remove broadcast bits from debugger
Removes the debugger broadcast bits from `Debugger.h` and instead uses
the enum from `lldb-enumerations.h`. Also adds the
`eBroadcastSymbolChange` bit to the enum in `lldb-enumerations.h`.
---
lldb/include/lldb/Core/Debugger.h | 11 +--
lldb/include/lldb/lldb-enumerations.h | 3 ++-
lldb/source/Core/Debugger.cpp | 17 +
lldb/source/Core/Progress.cpp | 2 +-
lldb/unittests/Core/DiagnosticEventTest.cpp | 17 +++--
lldb/unittests/Core/ProgressReportTest.cpp | 8
6 files changed, 24 insertions(+), 34 deletions(-)
diff --git a/lldb/include/lldb/Core/Debugger.h
b/lldb/include/lldb/Core/Debugger.h
index c0f7c732ad2d4..ea994bf8c28dd 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -78,15 +78,6 @@ class Debugger : public
std::enable_shared_from_this,
public UserID,
public Properties {
public:
- /// Broadcaster event bits definitions.
- enum {
-eBroadcastBitProgress = (1 << 0),
-eBroadcastBitWarning = (1 << 1),
-eBroadcastBitError = (1 << 2),
-eBroadcastSymbolChange = (1 << 3),
-eBroadcastBitProgressCategory = (1 << 4),
- };
-
using DebuggerList = std::vector;
static llvm::StringRef GetStaticBroadcasterClass();
@@ -628,7 +619,7 @@ class Debugger : public
std::enable_shared_from_this,
ReportProgress(uint64_t progress_id, std::string title, std::string details,
uint64_t completed, uint64_t total,
std::optional debugger_id,
- uint32_t progress_category_bit = eBroadcastBitProgress);
+ uint32_t progress_category_bit = lldb::eBroadcastBitProgress);
static void ReportDiagnosticImpl(lldb::Severity severity, std::string
message,
std::optional debugger_id,
diff --git a/lldb/include/lldb/lldb-enumerations.h
b/lldb/include/lldb/lldb-enumerations.h
index 437971b3364cd..8e05f6ba9c876 100644
--- a/lldb/include/lldb/lldb-enumerations.h
+++ b/lldb/include/lldb/lldb-enumerations.h
@@ -1344,7 +1344,8 @@ enum DebuggerBroadcastBit {
eBroadcastBitProgress = (1 << 0),
eBroadcastBitWarning = (1 << 1),
eBroadcastBitError = (1 << 2),
- eBroadcastBitProgressCategory = (1 << 3),
+ eBroadcastSymbolChange = (1 << 3),
+ eBroadcastBitProgressCategory = (1 << 4),
};
/// Used for expressing severity in logs and diagnostics.
diff --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 976420a434439..9951fbcd3e7c3 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -1485,10 +1485,10 @@ static void PrivateReportDiagnostic(Debugger ,
Severity severity,
assert(false && "eSeverityInfo should not be broadcast");
return;
case eSeverityWarning:
-event_type = Debugger::eBroadcastBitWarning;
+event_type = lldb::eBroadcastBitWarning;
break;
case eSeverityError:
-event_type = Debugger::eBroadcastBitError;
+event_type = lldb::eBroadcastBitError;
break;
}
@@ -1572,7 +1572,7 @@ void Debugger::ReportSymbolChange(const ModuleSpec
_spec) {
std::lock_guard guard(*g_debugger_list_mutex_ptr);
for (DebuggerSP debugger_sp : *g_debugger_list_ptr) {
EventSP event_sp = std::make_shared(
- Debugger::eBroadcastSymbolChange,
+ lldb::eBroadcastSymbolChange,
new SymbolChangeEventData(debugger_sp, module_spec));
debugger_sp->GetBroadcaster().BroadcastEvent(event_sp);
}
@@ -1879,8 +1879,9 @@ lldb::thread_result_t Debugger::DefaultEventHandler() {
CommandInterpreter::eBroadcastBitAsynchronousErrorData);
listener_sp->StartListeningForEvents(
- _broadcaster, eBroadcastBitProgress | eBroadcastBitWarning |
- eBroadcastBitError | eBroadcastSymbolChange);
+ _broadcaster, lldb::eBroadcastBitProgress | lldb::eBroadcastBitWarning
|
+ lldb::eBroadcastBitError |
+ lldb::eBroadcastSymbolChange);
// Let the thread that spawned us know that we have started up and that we
// are now listening to all required events so no events get missed
@@ -1932,11 +1933,11 @@ lldb::thread_result_t Debugger::DefaultEventHandler() {
}
}
} else if (broadcaster == _broadcaster) {
-if (event_type & Debugger::eBroadcastBitProgress)
+if (event_type & lldb::eBroadcastBitProgress)
HandleProgressEvent(event_sp);
-else if (event_type & Debugger::eBroadcastBitWarning)
+else if (event_type & lldb::eBroadcastBitWarning)
[Lldb-commits] [lldb] [lldb][enums] Remove broadcast bits from debugger (PR #91618)
https://github.com/bulbazord approved this pull request. https://github.com/llvm/llvm-project/pull/91618 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Update incorrect help message for `--no-crashed-only` option (PR #91162)
https://github.com/medismailben closed https://github.com/llvm/llvm-project/pull/91162 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 8585bf7 - [lldb/crashlog] Update incorrect help message for `--no-crashed-only` option (#91162)
Author: Med Ismail Bennani Date: 2024-05-09T10:19:34-07:00 New Revision: 8585bf7542f1098bd03a667a408d42d2a815d305 URL: https://github.com/llvm/llvm-project/commit/8585bf7542f1098bd03a667a408d42d2a815d305 DIFF: https://github.com/llvm/llvm-project/commit/8585bf7542f1098bd03a667a408d42d2a815d305.diff LOG: [lldb/crashlog] Update incorrect help message for `--no-crashed-only` option (#91162) This patch rephrases the crashlog `--no-crashed-only` option help message. This option is mainly used in batch mode to symbolicate and dump all the threads backtraces, instead of only doing it for the crashed thread which is the default behavior. rdar://127391524 Signed-off-by: Med Ismail Bennani Added: Modified: lldb/examples/python/crashlog.py Removed: diff --git a/lldb/examples/python/crashlog.py b/lldb/examples/python/crashlog.py index d147d0e322a3..eb9af6ed3d95 100755 --- a/lldb/examples/python/crashlog.py +++ b/lldb/examples/python/crashlog.py @@ -1649,7 +1649,8 @@ def CreateSymbolicateCrashLogOptions( "--no-crashed-only", action="store_false", dest="crashed_only", -help="do not symbolicate the crashed thread", +help="in batch mode, symbolicate all threads, not only the crashed one", +default=False, ) arg_parser.add_argument( "--disasm-depth", ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Enforce image loading policy (PR #91109)
https://github.com/medismailben closed https://github.com/llvm/llvm-project/pull/91109 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 785b143 - [lldb/crashlog] Enforce image loading policy (#91109)
Author: Med Ismail Bennani Date: 2024-05-09T10:13:20-07:00 New Revision: 785b143a402a282822c3d5e30bb4e2b1980c0b1e URL: https://github.com/llvm/llvm-project/commit/785b143a402a282822c3d5e30bb4e2b1980c0b1e DIFF: https://github.com/llvm/llvm-project/commit/785b143a402a282822c3d5e30bb4e2b1980c0b1e.diff LOG: [lldb/crashlog] Enforce image loading policy (#91109) In `27f27d1`, we changed the image loading logic to conform to the various options (`-a|--load-all` & `-c|--crashed-only`) and loaded them concurrently. However, instead of the subset of images that matched the user option, the thread pool would always run on all the crashlog images, causing them to be all loaded in the target everytime. This matches the `-a|--load-all` option behaviour but depending on the report, it can cause lldb to load thousands of images, which can take a very long time if the images are downloaded over the network. This patch fixes that issue by keeping a list of `images_to_load` based of the user-provided option. This list will be used with our executor thread pool to load the images according to the user selection, and reinstates the expected default behaviour, by only loading the crashed thread images and skipping all the others. This patch also unifies the way we load images into a single method that's shared by both the batch mode & the interactive scripted process. rdar://123694062 Signed-off-by: Med Ismail Bennani Added: Modified: lldb/examples/python/crashlog.py lldb/examples/python/crashlog_scripted_process.py Removed: diff --git a/lldb/examples/python/crashlog.py b/lldb/examples/python/crashlog.py index c992348b24be1..d147d0e322a33 100755 --- a/lldb/examples/python/crashlog.py +++ b/lldb/examples/python/crashlog.py @@ -252,7 +252,7 @@ def add_ident(self, ident): self.idents.append(ident) def did_crash(self): -return self.reason is not None +return self.crashed def __str__(self): if self.app_specific_backtrace: @@ -526,6 +526,49 @@ def create_target(self): def get_target(self): return self.target +def load_images(self, options, loaded_images=None): +if not loaded_images: +loaded_images = [] +images_to_load = self.images +if options.load_all_images: +for image in self.images: +image.resolve = True +elif options.crashed_only: +for thread in self.threads: +if thread.did_crash(): +images_to_load = [] +for ident in thread.idents: +for image in self.find_images_with_identifier(ident): +image.resolve = True +images_to_load.append(image) + +futures = [] +with tempfile.TemporaryDirectory() as obj_dir: +with concurrent.futures.ThreadPoolExecutor() as executor: + +def add_module(image, target, obj_dir): +return image, image.add_module(target, obj_dir) + +for image in images_to_load: +if image not in loaded_images: +if image.uuid == uuid.UUID(int=0): +continue +futures.append( +executor.submit( +add_module, +image=image, +target=self.target, +obj_dir=obj_dir, +) +) + +for future in concurrent.futures.as_completed(futures): +image, err = future.result() +if err: +print(err) +else: +loaded_images.append(image) + class CrashLogFormatException(Exception): pass @@ -1408,36 +1451,7 @@ def SymbolicateCrashLog(crash_log, options): if not target: return -if options.load_all_images: -for image in crash_log.images: -image.resolve = True -elif options.crashed_only: -for thread in crash_log.threads: -if thread.did_crash(): -for ident in thread.idents: -for image in crash_log.find_images_with_identifier(ident): -image.resolve = True - -futures = [] -loaded_images = [] -with tempfile.TemporaryDirectory() as obj_dir: -with concurrent.futures.ThreadPoolExecutor() as executor: - -def add_module(image, target, obj_dir): -return image, image.add_module(target, obj_dir) - -for image in crash_log.images: -futures.append( -executor.submit( -add_module, image=image, target=target,
[Lldb-commits] [lldb] [lldb/crashlog] Enforce image loading policy (PR #91109)
https://github.com/bulbazord approved this pull request. https://github.com/llvm/llvm-project/pull/91109 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/crashlog] Enforce image loading policy (PR #91109)
https://github.com/medismailben updated https://github.com/llvm/llvm-project/pull/91109 >From 625245737c31ac4e2cf04417bc8457caa461ef31 Mon Sep 17 00:00:00 2001 From: Med Ismail Bennani Date: Thu, 9 May 2024 10:02:50 -0700 Subject: [PATCH] [lldb/crashlog] Enforce image loading policy In `27f27d1`, we changed the image loading logic to conform to the various options (`-a|--load-all` & `-c|--crashed-only`) and loaded them concurrently. However, instead of the subset of images that matched the user option, the thread pool would always run on all the crashlog images, causing them to be all loaded in the target everytime. This matches the `-a|--load-all` option behaviour but depending on the report, it can cause lldb to load thousands of images, which can take a very long time if the images are downloaded over the network. This patch fixes that issue by keeping a list of `images_to_load` based of the user-provided option. This list will be used with our executor thread pool to load the images according to the user selection, and reinstates the expected default behaviour, by only loading the crashed thread images and skipping all the others. This patch also unifies the way we load images into a single method that's shared by both the batch mode & the interactive scripted process. rdar://123694062 Signed-off-by: Med Ismail Bennani --- lldb/examples/python/crashlog.py | 82 +++ .../python/crashlog_scripted_process.py | 38 +++-- 2 files changed, 63 insertions(+), 57 deletions(-) diff --git a/lldb/examples/python/crashlog.py b/lldb/examples/python/crashlog.py index c992348b24be1..d147d0e322a33 100755 --- a/lldb/examples/python/crashlog.py +++ b/lldb/examples/python/crashlog.py @@ -252,7 +252,7 @@ def add_ident(self, ident): self.idents.append(ident) def did_crash(self): -return self.reason is not None +return self.crashed def __str__(self): if self.app_specific_backtrace: @@ -526,6 +526,49 @@ def create_target(self): def get_target(self): return self.target +def load_images(self, options, loaded_images=None): +if not loaded_images: +loaded_images = [] +images_to_load = self.images +if options.load_all_images: +for image in self.images: +image.resolve = True +elif options.crashed_only: +for thread in self.threads: +if thread.did_crash(): +images_to_load = [] +for ident in thread.idents: +for image in self.find_images_with_identifier(ident): +image.resolve = True +images_to_load.append(image) + +futures = [] +with tempfile.TemporaryDirectory() as obj_dir: +with concurrent.futures.ThreadPoolExecutor() as executor: + +def add_module(image, target, obj_dir): +return image, image.add_module(target, obj_dir) + +for image in images_to_load: +if image not in loaded_images: +if image.uuid == uuid.UUID(int=0): +continue +futures.append( +executor.submit( +add_module, +image=image, +target=self.target, +obj_dir=obj_dir, +) +) + +for future in concurrent.futures.as_completed(futures): +image, err = future.result() +if err: +print(err) +else: +loaded_images.append(image) + class CrashLogFormatException(Exception): pass @@ -1408,36 +1451,7 @@ def SymbolicateCrashLog(crash_log, options): if not target: return -if options.load_all_images: -for image in crash_log.images: -image.resolve = True -elif options.crashed_only: -for thread in crash_log.threads: -if thread.did_crash(): -for ident in thread.idents: -for image in crash_log.find_images_with_identifier(ident): -image.resolve = True - -futures = [] -loaded_images = [] -with tempfile.TemporaryDirectory() as obj_dir: -with concurrent.futures.ThreadPoolExecutor() as executor: - -def add_module(image, target, obj_dir): -return image, image.add_module(target, obj_dir) - -for image in crash_log.images: -futures.append( -executor.submit( -add_module, image=image, target=target, obj_dir=obj_dir -) -) -for future in
[Lldb-commits] [lldb] [lldb][enums] Remove broadcast bits from debugger (PR #91618)
https://github.com/medismailben approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/91618 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/aarch64] Fix unwinding when signal interrupts a leaf function (PR #91321)
jasonmolenda wrote: Will debug this today. 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
[Lldb-commits] [lldb] [WIP] [lldb][Progress] Report progress when completing types from DWARF (PR #91452)
JDevlieghere wrote: > If this turns out to be necessary, one way to rate-limit them would be to > have a nesting depth counter. Assuming that these imports happen recursively > we could create only Progress objects for the top n layers. Is the code that emits the progress event recursive too? The reason I ask is because on the command line, nested progress events will get shadowed. The same is true for coalesced progress events. I'm not sure how VSCode/DAP clients deal with this, so maybe they're shown there? Anyway, if the code is recursive, we might need to do something like we did for Swift, with one top-level event and callback that updates the details. 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
[Lldb-commits] [lldb] [WIP] [lldb][Progress] Report progress when completing types from DWARF (PR #91452)
adrian-prantl wrote: If this turns out to be necessary, one way to rate-limit them would be to have a nesting depth counter. Assuming that these imports happen recursively we could create only Progress objects for the top n layers. 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
[Lldb-commits] [lldb] [lldb][enums] Remove broadcast bits from debugger (PR #91618)
https://github.com/JDevlieghere edited https://github.com/llvm/llvm-project/pull/91618 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][enums] Remove broadcast bits from debugger (PR #91618)
https://github.com/JDevlieghere approved this pull request. LGTM but let's give Alex and Ismail a chance to take a look too. https://github.com/llvm/llvm-project/pull/91618 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][enums] Remove broadcast bits from debugger (PR #91618)
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff fe0b7983a2f510cdede22cdf6c9227e32ded6a15
f338108d6b0cbb47e72663c58c1cbb17ee446cbc -- lldb/include/lldb/Core/Debugger.h
lldb/include/lldb/lldb-enumerations.h lldb/source/Core/Debugger.cpp
lldb/source/Core/Progress.cpp lldb/unittests/Core/DiagnosticEventTest.cpp
lldb/unittests/Core/ProgressReportTest.cpp
``
View the diff from clang-format here.
``diff
diff --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 1c2d4e378e..9951fbcd3e 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -1880,7 +1880,8 @@ lldb::thread_result_t Debugger::DefaultEventHandler() {
listener_sp->StartListeningForEvents(
_broadcaster, lldb::eBroadcastBitProgress | lldb::eBroadcastBitWarning
|
- lldb::eBroadcastBitError |
lldb::eBroadcastSymbolChange);
+ lldb::eBroadcastBitError |
+ lldb::eBroadcastSymbolChange);
// Let the thread that spawned us know that we have started up and that we
// are now listening to all required events so no events get missed
diff --git a/lldb/unittests/Core/DiagnosticEventTest.cpp
b/lldb/unittests/Core/DiagnosticEventTest.cpp
index 0916e05f78..1423f76b8b 100644
--- a/lldb/unittests/Core/DiagnosticEventTest.cpp
+++ b/lldb/unittests/Core/DiagnosticEventTest.cpp
@@ -56,8 +56,7 @@ TEST_F(DiagnosticEventTest, Warning) {
listener_sp->StartListeningForEvents(,
lldb::eBroadcastBitWarning);
- EXPECT_TRUE(
- broadcaster.EventTypeHasListeners(lldb::eBroadcastBitWarning));
+ EXPECT_TRUE(broadcaster.EventTypeHasListeners(lldb::eBroadcastBitWarning));
Debugger::ReportWarning("foo", debugger_sp->GetID());
@@ -80,8 +79,7 @@ TEST_F(DiagnosticEventTest, Error) {
Broadcaster = debugger_sp->GetBroadcaster();
ListenerSP listener_sp = Listener::MakeListener("test-listener");
- listener_sp->StartListeningForEvents(,
- lldb::eBroadcastBitError);
+ listener_sp->StartListeningForEvents(, lldb::eBroadcastBitError);
EXPECT_TRUE(broadcaster.EventTypeHasListeners(lldb::eBroadcastBitError));
Debugger::ReportError("bar", debugger_sp->GetID());
@@ -141,8 +139,7 @@ TEST_F(DiagnosticEventTest, WarningOnce) {
listener_sp->StartListeningForEvents(,
lldb::eBroadcastBitWarning);
- EXPECT_TRUE(
- broadcaster.EventTypeHasListeners(lldb::eBroadcastBitWarning));
+ EXPECT_TRUE(broadcaster.EventTypeHasListeners(lldb::eBroadcastBitWarning));
std::once_flag once;
Debugger::ReportWarning("foo", debugger_sp->GetID(), );
``
https://github.com/llvm/llvm-project/pull/91618
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)
@@ -237,6 +250,16 @@ class ProcessInstanceInfo : public ProcessInfo {
m_cumulative_system_time.tv_usec > 0;
}
+ int8_t GetNiceValue() const { return m_nice_value; }
feg208 wrote:
Done. Agreed. I also added a note in the linux specific code. In linuxland
priority implies a realtime priority while nice is nice
https://github.com/llvm/llvm-project/pull/91544
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)
@@ -237,6 +250,16 @@ class ProcessInstanceInfo : public ProcessInfo {
m_cumulative_system_time.tv_usec > 0;
}
+ int8_t GetNiceValue() const { return m_nice_value; }
+
+ void SetNiceValue(int8_t nice_value) { m_nice_value = nice_value; }
+
+ bool NiceValueIsValid() const;
+
+ void SetIsZombie() { m_zombie = true; }
feg208 wrote:
There is now
https://github.com/llvm/llvm-project/pull/91544
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)
@@ -17,6 +17,7 @@ #include #include +#include feg208 wrote: removed https://github.com/llvm/llvm-project/pull/91544 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)
@@ -117,6 +118,10 @@ bool ProcessInfo::IsScriptedProcess() const {
return m_scripted_metadata_sp && *m_scripted_metadata_sp;
}
+bool ProcessInstanceInfo::NiceValueIsValid() const {
+ return m_nice_value >= PRIO_MIN && m_nice_value <= PRIO_MAX;
feg208 wrote:
I removed this and just made the check to be a value stored in the optional
https://github.com/llvm/llvm-project/pull/91544
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][enums] Remove broadcast bits from debugger (PR #91618)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Chelsea Cassanova (chelcassanova)
Changes
Removes the debugger broadcast bits from `Debugger.h` and instead uses the enum
from `lldb-enumerations.h`. Also adds the `eBroadcastSymbolChange` bit to the
enum in `lldb-enumerations.h`.
---
Full diff: https://github.com/llvm/llvm-project/pull/91618.diff
6 Files Affected:
- (modified) lldb/include/lldb/Core/Debugger.h (+1-10)
- (modified) lldb/include/lldb/lldb-enumerations.h (+2-1)
- (modified) lldb/source/Core/Debugger.cpp (+8-8)
- (modified) lldb/source/Core/Progress.cpp (+1-1)
- (modified) lldb/unittests/Core/DiagnosticEventTest.cpp (+7-7)
- (modified) lldb/unittests/Core/ProgressReportTest.cpp (+4-4)
``diff
diff --git a/lldb/include/lldb/Core/Debugger.h
b/lldb/include/lldb/Core/Debugger.h
index c0f7c732ad2d..ea994bf8c28d 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -78,15 +78,6 @@ class Debugger : public
std::enable_shared_from_this,
public UserID,
public Properties {
public:
- /// Broadcaster event bits definitions.
- enum {
-eBroadcastBitProgress = (1 << 0),
-eBroadcastBitWarning = (1 << 1),
-eBroadcastBitError = (1 << 2),
-eBroadcastSymbolChange = (1 << 3),
-eBroadcastBitProgressCategory = (1 << 4),
- };
-
using DebuggerList = std::vector;
static llvm::StringRef GetStaticBroadcasterClass();
@@ -628,7 +619,7 @@ class Debugger : public
std::enable_shared_from_this,
ReportProgress(uint64_t progress_id, std::string title, std::string details,
uint64_t completed, uint64_t total,
std::optional debugger_id,
- uint32_t progress_category_bit = eBroadcastBitProgress);
+ uint32_t progress_category_bit = lldb::eBroadcastBitProgress);
static void ReportDiagnosticImpl(lldb::Severity severity, std::string
message,
std::optional debugger_id,
diff --git a/lldb/include/lldb/lldb-enumerations.h
b/lldb/include/lldb/lldb-enumerations.h
index 437971b3364c..8e05f6ba9c87 100644
--- a/lldb/include/lldb/lldb-enumerations.h
+++ b/lldb/include/lldb/lldb-enumerations.h
@@ -1344,7 +1344,8 @@ enum DebuggerBroadcastBit {
eBroadcastBitProgress = (1 << 0),
eBroadcastBitWarning = (1 << 1),
eBroadcastBitError = (1 << 2),
- eBroadcastBitProgressCategory = (1 << 3),
+ eBroadcastSymbolChange = (1 << 3),
+ eBroadcastBitProgressCategory = (1 << 4),
};
/// Used for expressing severity in logs and diagnostics.
diff --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 976420a43443..1c2d4e378e20 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -1485,10 +1485,10 @@ static void PrivateReportDiagnostic(Debugger ,
Severity severity,
assert(false && "eSeverityInfo should not be broadcast");
return;
case eSeverityWarning:
-event_type = Debugger::eBroadcastBitWarning;
+event_type = lldb::eBroadcastBitWarning;
break;
case eSeverityError:
-event_type = Debugger::eBroadcastBitError;
+event_type = lldb::eBroadcastBitError;
break;
}
@@ -1572,7 +1572,7 @@ void Debugger::ReportSymbolChange(const ModuleSpec
_spec) {
std::lock_guard guard(*g_debugger_list_mutex_ptr);
for (DebuggerSP debugger_sp : *g_debugger_list_ptr) {
EventSP event_sp = std::make_shared(
- Debugger::eBroadcastSymbolChange,
+ lldb::eBroadcastSymbolChange,
new SymbolChangeEventData(debugger_sp, module_spec));
debugger_sp->GetBroadcaster().BroadcastEvent(event_sp);
}
@@ -1879,8 +1879,8 @@ lldb::thread_result_t Debugger::DefaultEventHandler() {
CommandInterpreter::eBroadcastBitAsynchronousErrorData);
listener_sp->StartListeningForEvents(
- _broadcaster, eBroadcastBitProgress | eBroadcastBitWarning |
- eBroadcastBitError | eBroadcastSymbolChange);
+ _broadcaster, lldb::eBroadcastBitProgress | lldb::eBroadcastBitWarning
|
+ lldb::eBroadcastBitError |
lldb::eBroadcastSymbolChange);
// Let the thread that spawned us know that we have started up and that we
// are now listening to all required events so no events get missed
@@ -1932,11 +1932,11 @@ lldb::thread_result_t Debugger::DefaultEventHandler() {
}
}
} else if (broadcaster == _broadcaster) {
-if (event_type & Debugger::eBroadcastBitProgress)
+if (event_type & lldb::eBroadcastBitProgress)
HandleProgressEvent(event_sp);
-else if (event_type & Debugger::eBroadcastBitWarning)
+else if (event_type & lldb::eBroadcastBitWarning)
HandleDiagnosticEvent(event_sp);
-else if (event_type & Debugger::eBroadcastBitError)
+else if (event_type & lldb::eBroadcastBitError)
[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)
https://github.com/feg208 updated
https://github.com/llvm/llvm-project/pull/91544
>From 18b0d55d1c4e04842e531c7f7e304998f2b2ad4e Mon Sep 17 00:00:00 2001
From: Fred Grim
Date: Wed, 8 May 2024 15:36:16 -0700
Subject: [PATCH] [lldb] Adds additional fields to ProcessInfo
To implement SaveCore for elf binaries we need to populate some
additional fields in the prpsinfo struct. Those fields are the nice
value of the process whose core is to be taken as well as a boolean
flag indicating whether or not that process is a zombie. This commit
adds those as well as tests to ensure that the values are consistent
with expectations
---
lldb/include/lldb/Utility/ProcessInfo.h | 28 +++
lldb/source/Host/linux/Host.cpp | 45 ++---
lldb/source/Utility/ProcessInfo.cpp | 4 +++
lldb/unittests/Host/linux/HostTest.cpp | 20 +++
4 files changed, 77 insertions(+), 20 deletions(-)
diff --git a/lldb/include/lldb/Utility/ProcessInfo.h
b/lldb/include/lldb/Utility/ProcessInfo.h
index 54ac000dc7fc..240f78d1c4e4 100644
--- a/lldb/include/lldb/Utility/ProcessInfo.h
+++ b/lldb/include/lldb/Utility/ProcessInfo.h
@@ -15,6 +15,7 @@
#include "lldb/Utility/FileSpec.h"
#include "lldb/Utility/NameMatches.h"
#include "lldb/Utility/StructuredData.h"
+#include
#include
namespace lldb_private {
@@ -144,6 +145,19 @@ class ProcessInstanceInfo : public ProcessInfo {
long int tv_usec = 0;
};
+ enum class ProcessState {
+Unknown,
+Dead,
+DiskSleep,
+Idle,
+Paging,
+Parked,
+Running,
+Sleeping,
+TracedOrStopped,
+Zombie,
+ };
+
ProcessInstanceInfo() = default;
ProcessInstanceInfo(const char *name, const ArchSpec , lldb::pid_t pid)
@@ -237,6 +251,18 @@ class ProcessInstanceInfo : public ProcessInfo {
m_cumulative_system_time.tv_usec > 0;
}
+ int8_t GetPriorityValue() const { return m_priority_value.value(); }
+
+ void SetPriorityValue(int8_t priority_value) {
+m_priority_value = priority_value;
+ }
+
+ bool PriorityValueIsValid() const;
+
+ void SetIsZombie(bool is_zombie = true) { m_zombie = is_zombie; }
+
+ bool IsZombie() const { return m_zombie; }
+
void Dump(Stream , UserIDResolver ) const;
static void DumpTableHeader(Stream , bool show_args, bool verbose);
@@ -254,6 +280,8 @@ class ProcessInstanceInfo : public ProcessInfo {
struct timespec m_system_time {};
struct timespec m_cumulative_user_time {};
struct timespec m_cumulative_system_time {};
+ std::optional m_priority_value = std::nullopt;
+ bool m_zombie = false;
};
typedef std::vector ProcessInstanceInfoList;
diff --git a/lldb/source/Host/linux/Host.cpp b/lldb/source/Host/linux/Host.cpp
index c6490f2fc9e2..186323393c14 100644
--- a/lldb/source/Host/linux/Host.cpp
+++ b/lldb/source/Host/linux/Host.cpp
@@ -37,18 +37,8 @@ using namespace lldb;
using namespace lldb_private;
namespace {
-enum class ProcessState {
- Unknown,
- Dead,
- DiskSleep,
- Idle,
- Paging,
- Parked,
- Running,
- Sleeping,
- TracedOrStopped,
- Zombie,
-};
+
+using ProcessState = typename ProcessInstanceInfo::ProcessState;
constexpr int task_comm_len = 16;
@@ -70,6 +60,12 @@ struct StatFields {
long unsigned stime;
long cutime;
long cstime;
+ // in proc_pid_stat(5) this field is specified as priority
+ // but documented as realtime priority. To keep with the adopted
+ // nomenclature in ProcessInstanceInfo we adopt the documented
+ // naming here
+ long realtime_priority;
+ long priority;
// other things. We don't need them below
};
}
@@ -91,14 +87,16 @@ static bool GetStatusInfo(::pid_t Pid, ProcessInstanceInfo
,
if (Rest.empty())
return false;
StatFields stat_fields;
- if (sscanf(Rest.data(),
- "%d %s %c %d %d %d %d %d %u %lu %lu %lu %lu %lu %lu %ld %ld",
- _fields.pid, stat_fields.comm, _fields.state,
- _fields.ppid, _fields.pgrp, _fields.session,
- _fields.tty_nr, _fields.tpgid, _fields.flags,
- _fields.minflt, _fields.cminflt, _fields.majflt,
- _fields.cmajflt, _fields.utime, _fields.stime,
- _fields.cutime, _fields.cstime) < 0) {
+ if (sscanf(
+ Rest.data(),
+ "%d %s %c %d %d %d %d %d %u %lu %lu %lu %lu %lu %lu %ld %ld %ld %ld",
+ _fields.pid, stat_fields.comm, _fields.state,
+ _fields.ppid, _fields.pgrp, _fields.session,
+ _fields.tty_nr, _fields.tpgid, _fields.flags,
+ _fields.minflt, _fields.cminflt, _fields.majflt,
+ _fields.cmajflt, _fields.utime, _fields.stime,
+ _fields.cutime, _fields.cstime,
+ _fields.realtime_priority, _fields.priority) < 0) {
return false;
}
@@ -115,6 +113,11 @@ static bool GetStatusInfo(::pid_t Pid, ProcessInstanceInfo
,
return ts;
};
+ // priority (nice) values run from 19 to -20 inclusive (in linux). In the
+ // prpsinfo struct pr_nice is a char
+ auto priority_value =
[Lldb-commits] [lldb] [lldb][enums] Remove broadcast bits from debugger (PR #91618)
https://github.com/chelcassanova created
https://github.com/llvm/llvm-project/pull/91618
Removes the debugger broadcast bits from `Debugger.h` and instead uses the enum
from `lldb-enumerations.h`. Also adds the `eBroadcastSymbolChange` bit to the
enum in `lldb-enumerations.h`.
>From f338108d6b0cbb47e72663c58c1cbb17ee446cbc Mon Sep 17 00:00:00 2001
From: Chelsea Cassanova
Date: Thu, 9 May 2024 09:23:02 -0700
Subject: [PATCH] [lldb][enums] Remove broadcast bits from debugger
Removes the debugger broadcast bits from `Debugger.h` and instead uses
the enum from `lldb-enumerations.h`. Also adds the
`eBroadcastSymbolChange` bit to the enum in `lldb-enumerations.h`.
---
lldb/include/lldb/Core/Debugger.h | 11 +--
lldb/include/lldb/lldb-enumerations.h | 3 ++-
lldb/source/Core/Debugger.cpp | 16
lldb/source/Core/Progress.cpp | 2 +-
lldb/unittests/Core/DiagnosticEventTest.cpp | 14 +++---
lldb/unittests/Core/ProgressReportTest.cpp | 8
6 files changed, 23 insertions(+), 31 deletions(-)
diff --git a/lldb/include/lldb/Core/Debugger.h
b/lldb/include/lldb/Core/Debugger.h
index c0f7c732ad2d..ea994bf8c28d 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -78,15 +78,6 @@ class Debugger : public
std::enable_shared_from_this,
public UserID,
public Properties {
public:
- /// Broadcaster event bits definitions.
- enum {
-eBroadcastBitProgress = (1 << 0),
-eBroadcastBitWarning = (1 << 1),
-eBroadcastBitError = (1 << 2),
-eBroadcastSymbolChange = (1 << 3),
-eBroadcastBitProgressCategory = (1 << 4),
- };
-
using DebuggerList = std::vector;
static llvm::StringRef GetStaticBroadcasterClass();
@@ -628,7 +619,7 @@ class Debugger : public
std::enable_shared_from_this,
ReportProgress(uint64_t progress_id, std::string title, std::string details,
uint64_t completed, uint64_t total,
std::optional debugger_id,
- uint32_t progress_category_bit = eBroadcastBitProgress);
+ uint32_t progress_category_bit = lldb::eBroadcastBitProgress);
static void ReportDiagnosticImpl(lldb::Severity severity, std::string
message,
std::optional debugger_id,
diff --git a/lldb/include/lldb/lldb-enumerations.h
b/lldb/include/lldb/lldb-enumerations.h
index 437971b3364c..8e05f6ba9c87 100644
--- a/lldb/include/lldb/lldb-enumerations.h
+++ b/lldb/include/lldb/lldb-enumerations.h
@@ -1344,7 +1344,8 @@ enum DebuggerBroadcastBit {
eBroadcastBitProgress = (1 << 0),
eBroadcastBitWarning = (1 << 1),
eBroadcastBitError = (1 << 2),
- eBroadcastBitProgressCategory = (1 << 3),
+ eBroadcastSymbolChange = (1 << 3),
+ eBroadcastBitProgressCategory = (1 << 4),
};
/// Used for expressing severity in logs and diagnostics.
diff --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 976420a43443..1c2d4e378e20 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -1485,10 +1485,10 @@ static void PrivateReportDiagnostic(Debugger ,
Severity severity,
assert(false && "eSeverityInfo should not be broadcast");
return;
case eSeverityWarning:
-event_type = Debugger::eBroadcastBitWarning;
+event_type = lldb::eBroadcastBitWarning;
break;
case eSeverityError:
-event_type = Debugger::eBroadcastBitError;
+event_type = lldb::eBroadcastBitError;
break;
}
@@ -1572,7 +1572,7 @@ void Debugger::ReportSymbolChange(const ModuleSpec
_spec) {
std::lock_guard guard(*g_debugger_list_mutex_ptr);
for (DebuggerSP debugger_sp : *g_debugger_list_ptr) {
EventSP event_sp = std::make_shared(
- Debugger::eBroadcastSymbolChange,
+ lldb::eBroadcastSymbolChange,
new SymbolChangeEventData(debugger_sp, module_spec));
debugger_sp->GetBroadcaster().BroadcastEvent(event_sp);
}
@@ -1879,8 +1879,8 @@ lldb::thread_result_t Debugger::DefaultEventHandler() {
CommandInterpreter::eBroadcastBitAsynchronousErrorData);
listener_sp->StartListeningForEvents(
- _broadcaster, eBroadcastBitProgress | eBroadcastBitWarning |
- eBroadcastBitError | eBroadcastSymbolChange);
+ _broadcaster, lldb::eBroadcastBitProgress | lldb::eBroadcastBitWarning
|
+ lldb::eBroadcastBitError |
lldb::eBroadcastSymbolChange);
// Let the thread that spawned us know that we have started up and that we
// are now listening to all required events so no events get missed
@@ -1932,11 +1932,11 @@ lldb::thread_result_t Debugger::DefaultEventHandler() {
}
}
} else if (broadcaster == _broadcaster) {
-if (event_type & Debugger::eBroadcastBitProgress)
+if (event_type & lldb::eBroadcastBitProgress)
[Lldb-commits] [clang] [lldb] [llvm] [AArch64] move extension information into tablgen (PR #90987)
https://github.com/jroelofs approved this pull request. https://github.com/llvm/llvm-project/pull/90987 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)
@@ -237,6 +250,16 @@ class ProcessInstanceInfo : public ProcessInfo {
m_cumulative_system_time.tv_usec > 0;
}
+ int8_t GetNiceValue() const { return m_nice_value; }
emaste wrote:
nice and priority are not synonymous though, nice is one input into the
process's priority. I'm not sure which we actually want in this context.
https://github.com/llvm/llvm-project/pull/91544
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)
@@ -12,6 +12,9 @@ #include "lldb/Utility/ProcessInfo.h" #include "gtest/gtest.h" +#include +#include feg208 wrote: yeah. The cmake file enforces a linux-only build as well. However as @jimingham pointed out someone could plausibly move this into a non-linux build. Maybe I should place guards here and below? The functionality is in POSIX I think and my understanding is that windows would conform to POSIX to some degree. But to be honest I know very little about what happens on the windows side of the fence. https://github.com/llvm/llvm-project/pull/91544 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [WIP] [lldb][Progress] Report progress when completing types from DWARF (PR #91452)
JDevlieghere wrote: > My understanding was that the progress increment is designed to be really > cheap (writing two pointers) and that it's up to presentation layer to decide > a t what frequency to update the UI. > > @JDevlieghere — is that perception correct? You're correct about the presentation layer, but creating the progress reports isn't free and more recently we've added some bookkeeping to coalesce them. In the grand scheme of things they should be relatively cheap, but like timers I wouldn't put them in hot loops. 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
[Lldb-commits] [lldb] [lldb-dap] Fix a race during shutdown (PR #91591)
https://github.com/walter-erquinigo approved this pull request. This all makes sense to me. Thank you! 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
[Lldb-commits] [lldb] [WIP] [lldb][Progress] Report progress when completing types from DWARF (PR #91452)
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 takes so long simply because > > performing a very large number of these ops. > > Can you get some numbers on this? E.g., the number of events (per second?) > > that this generates, the timings of expression evaluation with/without the > > patch, or something like that? > > My understanding was that the progress increment is designed to be really > cheap (writing two pointers) and that it's up to presentation layer to decide > a t what frequency to update the UI. Even if the actual publishing of the progress event was free, there's still appears to be quite a bit of code executed before we reach that point. For example, the "if sending progress" block in `UpdateImportProgress` is 15 lines long, it definitely looks like it can end up allocating memory, etc. 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
[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)
@@ -254,6 +277,8 @@ class ProcessInstanceInfo : public ProcessInfo {
struct timespec m_system_time {};
struct timespec m_cumulative_user_time {};
struct timespec m_cumulative_system_time {};
+ int8_t m_nice_value = INT8_MAX;
feg208 wrote:
yeah. I'll make this change. Especially here since priority can be in a range
that has zero near the center
https://github.com/llvm/llvm-project/pull/91544
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)
@@ -144,6 +144,19 @@ class ProcessInstanceInfo : public ProcessInfo {
long int tv_usec = 0;
};
+ enum class ProcessState {
+Unknown,
+Dead,
+DiskSleep,
+Idle,
+Paging,
+Parked,
+Running,
+Sleeping,
+TracedOrStopped,
+Zombie,
+ };
+
feg208 wrote:
yeah. So if you look at the definition of ELFLinuxPrPsInfo there is a char
member `pr_state` that will be something like T or Z or whatever. So we'd need
these available to set that assuming we didn't want OS specific codes in there
which are very linux specific (I found the mapping in the linux kernel code).
Maybe we should move it back though? I mean for the purpose of generating a
core the state is always going to be TraceOrStopped in any case.
https://github.com/llvm/llvm-project/pull/91544
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb/aarch64] Fix unwinding when signal interrupts a leaf function (PR #91321)
adrian-prantl wrote: I think that would be a good start. Also tagging @jasonmolenda for advice. 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
[Lldb-commits] [lldb] [WIP] [lldb][Progress] Report progress when completing types from DWARF (PR #91452)
adrian-prantl 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 takes so long simply because > performing a very large number of these ops. > > Can you get some numbers on this? E.g., the number of events (per second?) > that this generates, the timings of expression evaluation with/without the > patch, or something like that? My understanding was that the progress increment is designed to be really cheap (writing two pointers) and that it's up to presentation layer to decide a t what frequency to update the UI. @JDevlieghere — is that perception correct? 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
[Lldb-commits] [lldb] [lldb][ELF] Move address class map into the symbol table (PR #91603)
DavidSpickett wrote: The only thing I can think of that breaks this is if some object wanted to use the same symbol table section, but interpret it in a different way that changed the address classes. I don't see any evidence of us doing that or needing to. Even if we did it'd probably change more than just address classes, and we'd be better off making a new copy of the parsed symbol table. https://github.com/llvm/llvm-project/pull/91603 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][ELF] Return address class map changes from symbol table parsing methods (PR #91585)
DavidSpickett wrote: Alternative: https://github.com/llvm/llvm-project/pull/91603 https://github.com/llvm/llvm-project/pull/91585 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][ELF] Move address class map into the symbol table (PR #91603)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: David Spickett (DavidSpickett)
Changes
Code in https://github.com/llvm/llvm-project/pull/90622 exposed a situation
where a symbol table may be loaded via a second copy of the same object.
This resulted in the first copy having its address class map updated, but not
the second. And it was that second one we used for symbol lookups, since it was
found by a plugin and we assume those to be more specific.
(the plugins returning the same file may itself be a bug)
I tried fixing this by returning the address map changes from the symbol table
parsing. Which works but it's awkward to make sure both object's maps get
updated.
Instead, this change moves the address class map into the symbol table, which
is shared between the objects already. ObjectFileELF::GetAddressClass was
already checking whether the symbol table existed anyway, so we are ok to use
it.
---
Full diff: https://github.com/llvm/llvm-project/pull/91603.diff
4 Files Affected:
- (modified) lldb/include/lldb/Symbol/Symtab.h (+15)
- (modified) lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp (+20-28)
- (modified) lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.h (-6)
- (modified) lldb/source/Symbol/Symtab.cpp (+19)
``diff
diff --git a/lldb/include/lldb/Symbol/Symtab.h
b/lldb/include/lldb/Symbol/Symtab.h
index 57627d2dde7d2..331716c3bac41 100644
--- a/lldb/include/lldb/Symbol/Symtab.h
+++ b/lldb/include/lldb/Symbol/Symtab.h
@@ -23,6 +23,8 @@ class Symtab {
public:
typedef std::vector IndexCollection;
typedef UniqueCStringMap NameToIndexMap;
+ typedef std::map
+ FileAddressToAddressClassMap;
enum Debug {
eDebugNo, // Not a debug symbol
@@ -239,6 +241,16 @@ class Symtab {
}
/// \}
+ /// Set the address class for the given address.
+ void SetAddressClass(lldb::addr_t addr,
+ lldb_private::AddressClass addr_class);
+
+ /// Lookup the address class of the given address.
+ ///
+ /// \return
+ /// The address' class, if it is known, otherwise AddressClass::eCode.
+ lldb_private::AddressClass GetAddressClass(lldb::addr_t addr);
+
protected:
typedef std::vector collection;
typedef collection::iterator iterator;
@@ -274,6 +286,9 @@ class Symtab {
collection m_symbols;
FileRangeToIndexMap m_file_addr_to_index;
+ /// The address class for each symbol in the elf file
+ FileAddressToAddressClassMap m_address_class_map;
+
/// Maps function names to symbol indices (grouped by FunctionNameTypes)
std::map>
m_name_to_symbol_indices;
diff --git a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
index 1646ee9aa34a6..9bfd05fddb4b0 100644
--- a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -769,17 +769,7 @@ AddressClass ObjectFileELF::GetAddressClass(addr_t
file_addr) {
if (res != AddressClass::eCode)
return res;
- auto ub = m_address_class_map.upper_bound(file_addr);
- if (ub == m_address_class_map.begin()) {
-// No entry in the address class map before the address. Return default
-// address class for an address in a code section.
-return AddressClass::eCode;
- }
-
- // Move iterator to the address class entry preceding address
- --ub;
-
- return ub->second;
+ return symtab->GetAddressClass(file_addr);
}
size_t ObjectFileELF::SectionIndex(const SectionHeaderCollIter ) {
@@ -2213,18 +2203,18 @@ unsigned ObjectFileELF::ParseSymbols(Symtab *symtab,
user_id_t start_id,
switch (mapping_symbol) {
case 'a':
// $a[.]* - marks an ARM instruction sequence
- m_address_class_map[symbol.st_value] = AddressClass::eCode;
+ symtab->SetAddressClass(symbol.st_value, AddressClass::eCode);
break;
case 'b':
case 't':
// $b[.]* - marks a THUMB BL instruction sequence
// $t[.]* - marks a THUMB instruction sequence
- m_address_class_map[symbol.st_value] =
- AddressClass::eCodeAlternateISA;
+ symtab->SetAddressClass(symbol.st_value,
+ AddressClass::eCodeAlternateISA);
break;
case 'd':
// $d[.]* - marks a data item sequence (e.g. lit pool)
- m_address_class_map[symbol.st_value] = AddressClass::eData;
+ symtab->SetAddressClass(symbol.st_value, AddressClass::eData);
break;
}
}
@@ -2238,11 +2228,11 @@ unsigned ObjectFileELF::ParseSymbols(Symtab *symtab,
user_id_t start_id,
switch (mapping_symbol) {
case 'x':
// $x[.]* - marks an A64 instruction sequence
- m_address_class_map[symbol.st_value] = AddressClass::eCode;
+ symtab->SetAddressClass(symbol.st_value,
[Lldb-commits] [lldb] [lldb][ELF] Move address class map into the symbol table (PR #91603)
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/91603
Code in https://github.com/llvm/llvm-project/pull/90622 exposed a situation
where a symbol table may be loaded via a second copy of the same object.
This resulted in the first copy having its address class map updated, but not
the second. And it was that second one we used for symbol lookups, since it was
found by a plugin and we assume those to be more specific.
(the plugins returning the same file may itself be a bug)
I tried fixing this by returning the address map changes from the symbol table
parsing. Which works but it's awkward to make sure both object's maps get
updated.
Instead, this change moves the address class map into the symbol table, which
is shared between the objects already. ObjectFileELF::GetAddressClass was
already checking whether the symbol table existed anyway, so we are ok to use
it.
>From 9187bbfc99a16803c56a3cf679695f511354d9c9 Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Thu, 9 May 2024 14:37:30 +
Subject: [PATCH] [lldb][ELF] Move address class map into the symbol table
Code in https://github.com/llvm/llvm-project/pull/90622 exposed a situation
where a symbol table may be loaded via a second copy of the same object.
This resulted in the first copy having its address class map updated, but
not the second. And it was that second one we used for symbol lookups,
since it was found by a plugin and we assume those to be more specific.
(the plugins returning the same file may itself be a bug)
I tried fixing this by returning the address map changes from the
symbol table parsing. Which works but it's awkward to make sure
both object's maps get updated.
Instead, this change moves the address class map into the symbol table,
which is shared between the objects already. ObjectFileELF::GetAddressClass
was already checking whether the symbol table existed anyway,
so we are ok to use it.
---
lldb/include/lldb/Symbol/Symtab.h | 15 ++
.../Plugins/ObjectFile/ELF/ObjectFileELF.cpp | 48 ---
.../Plugins/ObjectFile/ELF/ObjectFileELF.h| 6 ---
lldb/source/Symbol/Symtab.cpp | 19
4 files changed, 54 insertions(+), 34 deletions(-)
diff --git a/lldb/include/lldb/Symbol/Symtab.h
b/lldb/include/lldb/Symbol/Symtab.h
index 57627d2dde7d2..331716c3bac41 100644
--- a/lldb/include/lldb/Symbol/Symtab.h
+++ b/lldb/include/lldb/Symbol/Symtab.h
@@ -23,6 +23,8 @@ class Symtab {
public:
typedef std::vector IndexCollection;
typedef UniqueCStringMap NameToIndexMap;
+ typedef std::map
+ FileAddressToAddressClassMap;
enum Debug {
eDebugNo, // Not a debug symbol
@@ -239,6 +241,16 @@ class Symtab {
}
/// \}
+ /// Set the address class for the given address.
+ void SetAddressClass(lldb::addr_t addr,
+ lldb_private::AddressClass addr_class);
+
+ /// Lookup the address class of the given address.
+ ///
+ /// \return
+ /// The address' class, if it is known, otherwise AddressClass::eCode.
+ lldb_private::AddressClass GetAddressClass(lldb::addr_t addr);
+
protected:
typedef std::vector collection;
typedef collection::iterator iterator;
@@ -274,6 +286,9 @@ class Symtab {
collection m_symbols;
FileRangeToIndexMap m_file_addr_to_index;
+ /// The address class for each symbol in the elf file
+ FileAddressToAddressClassMap m_address_class_map;
+
/// Maps function names to symbol indices (grouped by FunctionNameTypes)
std::map>
m_name_to_symbol_indices;
diff --git a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
index 1646ee9aa34a6..9bfd05fddb4b0 100644
--- a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -769,17 +769,7 @@ AddressClass ObjectFileELF::GetAddressClass(addr_t
file_addr) {
if (res != AddressClass::eCode)
return res;
- auto ub = m_address_class_map.upper_bound(file_addr);
- if (ub == m_address_class_map.begin()) {
-// No entry in the address class map before the address. Return default
-// address class for an address in a code section.
-return AddressClass::eCode;
- }
-
- // Move iterator to the address class entry preceding address
- --ub;
-
- return ub->second;
+ return symtab->GetAddressClass(file_addr);
}
size_t ObjectFileELF::SectionIndex(const SectionHeaderCollIter ) {
@@ -2213,18 +2203,18 @@ unsigned ObjectFileELF::ParseSymbols(Symtab *symtab,
user_id_t start_id,
switch (mapping_symbol) {
case 'a':
// $a[.]* - marks an ARM instruction sequence
- m_address_class_map[symbol.st_value] = AddressClass::eCode;
+ symtab->SetAddressClass(symbol.st_value, AddressClass::eCode);
break;
case 'b':
case 't':
// $b[.]* - marks a THUMB BL instruction sequence
[Lldb-commits] [lldb] [lldb][DWARF] Sort ranges list in dwarf 5. (PR #91343)
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
[Lldb-commits] [lldb] fdede92 - [lldb][DWARF] Sort ranges list in dwarf 5. (#91343)
Author: Zequan Wu
Date: 2024-05-09T10:42:53-04:00
New Revision: fdede92d435068f31e7ea3a1dddb46d50343dd8c
URL:
https://github.com/llvm/llvm-project/commit/fdede92d435068f31e7ea3a1dddb46d50343dd8c
DIFF:
https://github.com/llvm/llvm-project/commit/fdede92d435068f31e7ea3a1dddb46d50343dd8c.diff
LOG: [lldb][DWARF] Sort ranges list in dwarf 5. (#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.
For example, when [parsing function
info](https://github.com/llvm/llvm-project/blob/bc8a42762057d7036f6871211e62b1c3efb2738a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp#L922-L927),
it validates low and hi address of the function: GetMinRangeBase returns
the first range entry base and GetMaxRangeEnd returns the last range
end. If low >= hi, it stops parsing this function. This causes missing
inline stack frames for those functions.
This change fixes it and updates the test
`lldb/test/Shell/SymbolFile/DWARF/x86/debug_rnglists.s` so that two
ranges in `.debug_rnglists` are out of order and `image lookup -v -s
lookup_rnglists` is still able to produce sorted ranges for the inner
block.
Added:
Modified:
lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
lldb/test/Shell/SymbolFile/DWARF/x86/debug_rnglists.s
Removed:
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
index dabc595427dfa..3a57ec970b071 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
@@ -1062,6 +1062,7 @@ DWARFUnit::FindRnglistFromOffset(dw_offset_t offset) {
ranges.Append(DWARFRangeList::Entry(llvm_range.LowPC,
llvm_range.HighPC - llvm_range.LowPC));
}
+ ranges.Sort();
return ranges;
}
diff --git a/lldb/test/Shell/SymbolFile/DWARF/x86/debug_rnglists.s
b/lldb/test/Shell/SymbolFile/DWARF/x86/debug_rnglists.s
index 89b5d94c68c3b..af8a1796f3abe 100644
--- a/lldb/test/Shell/SymbolFile/DWARF/x86/debug_rnglists.s
+++ b/lldb/test/Shell/SymbolFile/DWARF/x86/debug_rnglists.s
@@ -124,12 +124,12 @@ lookup_rnglists2:
.Lrnglists_table_base0:
.long .Ldebug_ranges0-.Lrnglists_table_base0
.Ldebug_ranges0:
-.byte 4 # DW_RLE_offset_pair
-.uleb128 .Lblock1_begin-rnglists # starting offset
-.uleb128 .Lblock1_end-rnglists# ending offset
.byte 4 # DW_RLE_offset_pair
.uleb128 .Lblock2_begin-rnglists # starting offset
.uleb128 .Lblock2_end-rnglists# ending offset
+.byte 4 # DW_RLE_offset_pair
+.uleb128 .Lblock1_begin-rnglists # starting offset
+.uleb128 .Lblock1_end-rnglists# ending offset
.byte 0 # DW_RLE_end_of_list
.Ldebug_rnglist_table_end0:
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][ELF] Return address class map changes from symbol table parsing methods (PR #91585)
DavidSpickett 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 made to it, so the caller can do the same. But now I've done that I'm wondering why this map doesn't live in the symbol table object itself, so I'm gonna try doing that. https://github.com/llvm/llvm-project/pull/91585 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][ELF] Return address class map changes from symbol table parsing methods (PR #91585)
https://github.com/DavidSpickett edited https://github.com/llvm/llvm-project/pull/91585 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][ELF] Return address class map changes from symbol table parsing methods (PR #91585)
https://github.com/DavidSpickett edited https://github.com/llvm/llvm-project/pull/91585 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][ELF] Return address class map from symbol table parsing methods (PR #91585)
https://github.com/DavidSpickett updated
https://github.com/llvm/llvm-project/pull/91585
>From 34c5ac8292b34d96039c6c69326f3fceb5cc3499 Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Thu, 9 May 2024 11:23:32 +
Subject: [PATCH 1/2] [lldb][ELF] Return address class map from symbol table
parsing methods
Instead of updating the member of the ObjectFileELF instance.
This means that if one object file asks another to parse the symbol table,
that first object's address class map is not left empty, which would
break Arm and MIPS targets that need this information.
This will fix the code added in
https://github.com/llvm/llvm-project/pull/90622 which broke
the test `Expr/TestStringLiteralExpr.test` on 32 bit Arm Linux.
This happened because we had the program file, then asked for a better
object file, which returned the same program file again. This creates
a second ObjectFileELF for the same file, so when we tell the second
instance to parse the symbol table it actually calls into the first
instance, leaving the address class map of the second instance empty.
Which caused us to put an Arm breakpoint instuction at a Thumb
return address and broke the ability to call mmap.
---
.../Plugins/ObjectFile/ELF/ObjectFileELF.cpp | 68 +++
.../Plugins/ObjectFile/ELF/ObjectFileELF.h| 21 +++---
2 files changed, 51 insertions(+), 38 deletions(-)
diff --git a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
index 1646ee9aa34a6..c216cc2d054c8 100644
--- a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -2060,13 +2060,14 @@ static char FindArmAarch64MappingSymbol(const char
*symbol_name) {
#define IS_MICROMIPS(ST_OTHER) (((ST_OTHER)_MIPS_ISA) == STO_MICROMIPS)
// private
-unsigned ObjectFileELF::ParseSymbols(Symtab *symtab, user_id_t start_id,
- SectionList *section_list,
- const size_t num_symbols,
- const DataExtractor _data,
- const DataExtractor _data) {
+std::pair
+ObjectFileELF::ParseSymbols(Symtab *symtab, user_id_t start_id,
+SectionList *section_list, const size_t
num_symbols,
+const DataExtractor _data,
+const DataExtractor _data) {
ELFSymbol symbol;
lldb::offset_t offset = 0;
+ FileAddressToAddressClassMap address_class_map;
static ConstString text_section_name(".text");
static ConstString init_section_name(".init");
@@ -2213,18 +2214,18 @@ unsigned ObjectFileELF::ParseSymbols(Symtab *symtab,
user_id_t start_id,
switch (mapping_symbol) {
case 'a':
// $a[.]* - marks an ARM instruction sequence
- m_address_class_map[symbol.st_value] = AddressClass::eCode;
+ address_class_map[symbol.st_value] = AddressClass::eCode;
break;
case 'b':
case 't':
// $b[.]* - marks a THUMB BL instruction sequence
// $t[.]* - marks a THUMB instruction sequence
- m_address_class_map[symbol.st_value] =
+ address_class_map[symbol.st_value] =
AddressClass::eCodeAlternateISA;
break;
case 'd':
// $d[.]* - marks a data item sequence (e.g. lit pool)
- m_address_class_map[symbol.st_value] = AddressClass::eData;
+ address_class_map[symbol.st_value] = AddressClass::eData;
break;
}
}
@@ -2238,11 +2239,11 @@ unsigned ObjectFileELF::ParseSymbols(Symtab *symtab,
user_id_t start_id,
switch (mapping_symbol) {
case 'x':
// $x[.]* - marks an A64 instruction sequence
- m_address_class_map[symbol.st_value] = AddressClass::eCode;
+ address_class_map[symbol.st_value] = AddressClass::eCode;
break;
case 'd':
// $d[.]* - marks a data item sequence (e.g. lit pool)
- m_address_class_map[symbol.st_value] = AddressClass::eData;
+ address_class_map[symbol.st_value] = AddressClass::eData;
break;
}
}
@@ -2260,11 +2261,11 @@ unsigned ObjectFileELF::ParseSymbols(Symtab *symtab,
user_id_t start_id,
// conjunction with symbol.st_value to produce the final
// symbol_value that we store in the symtab.
symbol_value_offset = -1;
-m_address_class_map[symbol.st_value ^ 1] =
+address_class_map[symbol.st_value ^ 1] =
AddressClass::eCodeAlternateISA;
} else {
// This address is ARM
-m_address_class_map[symbol.st_value] = AddressClass::eCode;
+address_class_map[symbol.st_value] =
[Lldb-commits] [lldb] [lldb] Improve type name parsing (PR #91586)
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 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
same thing, and getting it (mostly (*)) right. This refactors the function
so that it can return the scope results, fixing the parsing of names
like std::vector>::iterator.
Two callers of GetTypeScopeAndBasename are deleted as the functions are
not used (I presume they stopped being used once we started pruning type
search results more eagerly).
(*) This implementation is still not correct when one takes c++
operators into account -- e.g., something like `X<::operator<>::T`
is a legitimate type name. We do have an implementation that is able to
handle names like these (CPlusPlusLanguage::MethodName), but using it is
not trivial, because it is hidden in a language plugin and specific to
method name parsing.
---
lldb/include/lldb/Symbol/Type.h | 35 -
lldb/include/lldb/Symbol/TypeList.h | 9 --
lldb/include/lldb/Symbol/TypeMap.h| 4 -
lldb/source/Symbol/Type.cpp | 130 --
lldb/source/Symbol/TypeList.cpp | 109 ---
lldb/source/Symbol/TypeMap.cpp| 73 --
.../python_api/sbmodule/FindTypes/Makefile| 3 +
.../FindTypes/TestSBModuleFindTypes.py| 40 ++
.../python_api/sbmodule/FindTypes/main.cpp| 17 +++
lldb/unittests/Symbol/TestType.cpp| 62 -
10 files changed, 180 insertions(+), 302 deletions(-)
create mode 100644 lldb/test/API/python_api/sbmodule/FindTypes/Makefile
create mode 100644
lldb/test/API/python_api/sbmodule/FindTypes/TestSBModuleFindTypes.py
create mode 100644 lldb/test/API/python_api/sbmodule/FindTypes/main.cpp
diff --git a/lldb/include/lldb/Symbol/Type.h b/lldb/include/lldb/Symbol/Type.h
index 1c4f7b5601b0c..4194639dcfd2a 100644
--- a/lldb/include/lldb/Symbol/Type.h
+++ b/lldb/include/lldb/Symbol/Type.h
@@ -21,6 +21,8 @@
#include "llvm/ADT/APSInt.h"
#include "llvm/ADT/DenseSet.h"
+#include "llvm/ADT/STLForwardCompat.h"
+#include "llvm/Support/raw_ostream.h"
#include
#include
@@ -492,12 +494,37 @@ class Type : public std::enable_shared_from_this,
public UserID {
static int Compare(const Type , const Type );
+ // Represents a parsed type name coming out of GetTypeScopeAndBasename. The
+ // structure holds StringRefs pointing to portions of the original name, and
+ // so most not be used after the name is destroyed.
+ struct ParsedName {
+lldb::TypeClass type_class = lldb::eTypeClassAny;
+
+// Scopes of the type, starting with the outermost. Absolute type
references
+// have a "::" as the first scope.
+llvm::SmallVector scope;
+
+llvm::StringRef basename;
+
+friend bool operator==(const ParsedName , const ParsedName ) {
+ return lhs.type_class == rhs.type_class && lhs.scope == rhs.scope &&
+ lhs.basename == rhs.basename;
+}
+
+friend llvm::raw_ostream <<(llvm::raw_ostream ,
+ const ParsedName ) {
+ return os << llvm::formatv(
+ "Type::ParsedName({0:x}, [{1}], {2})",
+ llvm::to_underlying(name.type_class),
+ llvm::make_range(name.scope.begin(), name.scope.end()),
+ name.basename);
+}
+ };
// From a fully qualified typename, split the type into the type basename and
// the remaining type scope (namespaces/classes).
- static bool GetTypeScopeAndBasename(llvm::StringRef name,
- llvm::StringRef ,
- llvm::StringRef ,
- lldb::TypeClass _class);
+ static std::optional
+ GetTypeScopeAndBasename(llvm::StringRef name);
+
void SetEncodingType(Type *encoding_type) { m_encoding_type = encoding_type;
}
uint32_t GetEncodingMask();
diff --git a/lldb/include/lldb/Symbol/TypeList.h
b/lldb/include/lldb/Symbol/TypeList.h
index 403469c989f58..d58772ad5b62e 100644
--- a/lldb/include/lldb/Symbol/TypeList.h
+++ b/lldb/include/lldb/Symbol/TypeList.h
@@ -49,15 +49,6 @@ class TypeList {
void ForEach(std::function const );
- void RemoveMismatchedTypes(llvm::StringRef qualified_typename,
- bool exact_match);
-
- void RemoveMismatchedTypes(llvm::StringRef type_scope,
- llvm::StringRef type_basename,
- lldb::TypeClass type_class, bool exact_match);
-
- void RemoveMismatchedTypes(lldb::TypeClass type_class);
-
private:
typedef collection::iterator iterator;
typedef
[Lldb-commits] [lldb] [lldb][ELF] Return address class map from symbol table parsing methods (PR #91585)
DavidSpickett wrote: We can compare against the path the plugin found, though it's surprising that the plugins return anything at all so maybe there is a bug there too. It'll need a new test case, as `TestStringLiteralExpr.test` will no longer hit the code I'm changing in this PR, so I'll do it as a follow up. https://github.com/llvm/llvm-project/pull/91585 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Fix a race during shutdown (PR #91591)
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
justification for this in the protocol spec. The only way I found to shut the
server down was to send it a disconnect request.
- the flag did not actually work most of the time, because it's only checked
between requests so nothing will happen if the server starts listening for a
new request before a different thread manages to send the terminated event. And
since the next request is usually the disconnect request, everything will
operate normally.
The combination of these two things meant that the issue was largely
unnoticable, except for rare flaky test failures, which happened when the
handler thread was too slow, and checked the flag after it has already been
said. This caused the test suite to complain as it did not get a response to
the disconnect request. This situation could be s(t)imulated by adding a sleep
to the and of the main loop, which delayed the flag check, and caused the DAP
tests to fail reliably.
This patch changes the shutdown condition to only trigger when the disconnect
request has been received. Since the flag can now only be set from the handler
thread, it no longer needs to be atomic.
>From 2d9aaa5260f9a7b00563c84a111d81050518851c Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Thu, 9 May 2024 13:10:53 +
Subject: [PATCH] [lldb-dap] Fix a race during shutdown
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
justification for this in the protocol spec. The only way I found to
shut the server down was to send it a disconnect request.
- the flag did not actually work most of the time, because it's only
checked between requests so nothing will happen if the server starts
listening for a new request before a different thread manages to send
the terminated event. And since the next request is usually the
disconnect request, everything will operate normally.
The combination of these two things meant that the issue was largely
unnoticable, except for rare flaky test failures, which happened when
the handler thread was too slow, and checked the flag after it has
already been said. This caused the test suite to complain as it did not
get a response to the disconnect request. This situation could be
s(t)imulated by adding a sleep to the and of the main loop, which
delayed the flag check, and caused the DAP tests to fail reliably.
This patch changes the shutdown condition to only trigger when the
disconnect request has been received. Since the flag can now only be set
from the handler thread, it no longer needs to be atomic.
---
lldb/tools/lldb-dap/DAP.cpp | 5 ++---
lldb/tools/lldb-dap/DAP.h| 2 +-
lldb/tools/lldb-dap/lldb-dap.cpp | 25 +++--
3 files changed, 10 insertions(+), 22 deletions(-)
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index b254ddfef0d5f..55ff1493c1011 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -39,8 +39,7 @@ DAP::DAP()
{"objc_throw", "Objective-C Throw", lldb::eLanguageTypeObjC},
{"swift_catch", "Swift Catch", lldb::eLanguageTypeSwift},
{"swift_throw", "Swift Throw", lldb::eLanguageTypeSwift}}),
- focus_tid(LLDB_INVALID_THREAD_ID), sent_terminated_event(false),
- stop_at_entry(false), is_attach(false),
+ focus_tid(LLDB_INVALID_THREAD_ID), stop_at_entry(false),
is_attach(false),
enable_auto_variable_summaries(false),
enable_synthetic_child_debugging(false),
restarting_process_id(LLDB_INVALID_PROCESS_ID),
@@ -623,7 +622,7 @@ bool DAP::HandleObject(const llvm::json::Object ) {
}
llvm::Error DAP::Loop() {
- while (!sent_terminated_event) {
+ while (!disconnecting) {
llvm::json::Object object;
lldb_dap::PacketStatus status = GetNextObject(object);
diff --git a/lldb/tools/lldb-dap/DAP.h b/lldb/tools/lldb-dap/DAP.h
index 5c70a056fea4b..bbd9d46ba3a04 100644
--- a/lldb/tools/lldb-dap/DAP.h
+++ b/lldb/tools/lldb-dap/DAP.h
@@ -168,7 +168,7 @@ struct DAP {
// arguments if we get a RestartRequest.
std::optional last_launch_or_attach_request;
lldb::tid_t focus_tid;
- std::atomic sent_terminated_event;
+ bool disconnecting = false;
bool stop_at_entry;
bool is_attach;
bool enable_auto_variable_summaries;
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index f35abd665e844..96da458be21d1 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -226,26 +226,14 @@ void SendContinuedEvent() {
// Send a "terminated" event to indicate the process
[Lldb-commits] [lldb] [lldb-dap] Fix a race during shutdown (PR #91591)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Pavel Labath (labath)
Changes
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
justification for this in the protocol spec. The only way I found to shut the
server down was to send it a disconnect request.
- the flag did not actually work most of the time, because it's only checked
between requests so nothing will happen if the server starts listening for a
new request before a different thread manages to send the terminated event. And
since the next request is usually the disconnect request, everything will
operate normally.
The combination of these two things meant that the issue was largely
unnoticable, except for rare flaky test failures, which happened when the
handler thread was too slow, and checked the flag after it has already been
said. This caused the test suite to complain as it did not get a response to
the disconnect request. This situation could be s(t)imulated by adding a sleep
to the and of the main loop, which delayed the flag check, and caused the DAP
tests to fail reliably.
This patch changes the shutdown condition to only trigger when the disconnect
request has been received. Since the flag can now only be set from the handler
thread, it no longer needs to be atomic.
---
Full diff: https://github.com/llvm/llvm-project/pull/91591.diff
3 Files Affected:
- (modified) lldb/tools/lldb-dap/DAP.cpp (+2-3)
- (modified) lldb/tools/lldb-dap/DAP.h (+1-1)
- (modified) lldb/tools/lldb-dap/lldb-dap.cpp (+7-18)
``diff
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index b254ddfef0d5f..55ff1493c1011 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -39,8 +39,7 @@ DAP::DAP()
{"objc_throw", "Objective-C Throw", lldb::eLanguageTypeObjC},
{"swift_catch", "Swift Catch", lldb::eLanguageTypeSwift},
{"swift_throw", "Swift Throw", lldb::eLanguageTypeSwift}}),
- focus_tid(LLDB_INVALID_THREAD_ID), sent_terminated_event(false),
- stop_at_entry(false), is_attach(false),
+ focus_tid(LLDB_INVALID_THREAD_ID), stop_at_entry(false),
is_attach(false),
enable_auto_variable_summaries(false),
enable_synthetic_child_debugging(false),
restarting_process_id(LLDB_INVALID_PROCESS_ID),
@@ -623,7 +622,7 @@ bool DAP::HandleObject(const llvm::json::Object ) {
}
llvm::Error DAP::Loop() {
- while (!sent_terminated_event) {
+ while (!disconnecting) {
llvm::json::Object object;
lldb_dap::PacketStatus status = GetNextObject(object);
diff --git a/lldb/tools/lldb-dap/DAP.h b/lldb/tools/lldb-dap/DAP.h
index 5c70a056fea4b..bbd9d46ba3a04 100644
--- a/lldb/tools/lldb-dap/DAP.h
+++ b/lldb/tools/lldb-dap/DAP.h
@@ -168,7 +168,7 @@ struct DAP {
// arguments if we get a RestartRequest.
std::optional last_launch_or_attach_request;
lldb::tid_t focus_tid;
- std::atomic sent_terminated_event;
+ bool disconnecting = false;
bool stop_at_entry;
bool is_attach;
bool enable_auto_variable_summaries;
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index f35abd665e844..96da458be21d1 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -226,26 +226,14 @@ void SendContinuedEvent() {
// Send a "terminated" event to indicate the process is done being
// debugged.
void SendTerminatedEvent() {
- // If an inferior exits prior to the processing of a disconnect request, then
- // the threads executing EventThreadFunction and request_discontinue
- // respectively may call SendTerminatedEvent simultaneously. Without any
- // synchronization, the thread executing EventThreadFunction may set
- // g_dap.sent_terminated_event before the thread executing
- // request_discontinue has had a chance to test it, in which case the latter
- // would move ahead to issue a response to the disconnect request. Said
- // response may get dispatched ahead of the terminated event compelling the
- // client to terminate the debug session without consuming any console output
- // that might've been generated by the execution of terminateCommands. So,
- // synchronize simultaneous calls to SendTerminatedEvent.
+ // Prevent races if the process exits while we're being asked to disconnect.
static std::mutex mutex;
std::lock_guard locker(mutex);
- if (!g_dap.sent_terminated_event) {
-g_dap.sent_terminated_event = true;
-g_dap.RunTerminateCommands();
-// Send a "terminated" event
-llvm::json::Object event(CreateTerminatedEventObject());
-g_dap.SendJSON(llvm::json::Value(std::move(event)));
- }
+
+ g_dap.RunTerminateCommands();
+ // Send a "terminated" event
+ llvm::json::Object event(CreateTerminatedEventObject());
+ g_dap.SendJSON(llvm::json::Value(std::move(event)));
}
//
[Lldb-commits] [lldb] [lldb-dap] Fix a race during shutdown (PR #91591)
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://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Improve type name parsing (PR #91586)
https://github.com/Michael137 approved this pull request. Looks much cleaner now, thanks! 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
