[Lldb-commits] [clang] [clang-tools-extra] [lldb] [llvm] [SystemZ][z/OS] Propagate IsText parameter to open text files as text (PR #107906)

[kadir çetinkaya via lldb-commits]

kadircet wrote:

i think limiting this to `RealFileSystem::openFileForRead` LG, but can we make 
sure `IsText` defaults to `false` and we can only set it in `#ifdef __MVS__` 
block to make sure this is really a no-op for other platforms. e.g.:
```cppp
auto OpenFlags = sys::fs::OF_None;
#ifdef __MVS__

  OpenFlags |= sys::fs::OF_Text;

#endif
   Expected FDOrErr = sys::fs::openNativeFileForRead(
  adjustPath(Name, Storage), OpenFlags, &RealName);
```

I'd still prefer doing this inside 
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Support/Unix/Path.inc#L972-L1118
 as we have other utility functions that create file-descriptors and all of 
them end up using these base functions. By having your logic at a layer above 
these, you risk having subtle discrepancies. But I don't know much about zOS or 
why this is needed, so I'll leave management of that risk to you.

https://github.com/llvm/llvm-project/pull/107906
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][FreeBSD] Fix a typo in NativeProcessFreeBSD::MonitorSIGTRAP() (PR #109643)

[Kelvin Lee via lldb-commits]

https://github.com/kiyolee updated 
https://github.com/llvm/llvm-project/pull/109643

>From 3990c1616403808000241c93fa38b44e2d7f966a Mon Sep 17 00:00:00 2001
From: Kelvin Lee 
Date: Mon, 23 Sep 2024 19:43:20 +1000
Subject: [PATCH] [lldb][FreeBSD] Fix a typo in
 NativeProcessFreeBSD::MonitorSIGTRAP()

---
 lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp 
b/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
index 80b27571f43d55..bf552e19742c4a 100644
--- a/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
+++ b/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
@@ -324,7 +324,7 @@ void NativeProcessFreeBSD::MonitorSIGTRAP(lldb::pid_t pid) {
 auto thread_info =
 m_threads_stepping_with_breakpoint.find(thread->GetID());
 if (thread_info != m_threads_stepping_with_breakpoint.end() &&
-threads_info->second == regctx.GetPC()) {
+thread_info->second == regctx.GetPC()) {
   thread->SetStoppedByTrace();
   Status brkpt_error = RemoveBreakpoint(thread_info->second);
   if (brkpt_error.Fail())

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

[Lldb-commits] [lldb] [lldb][FreeBSD] Fix a typo in NativeProcessFreeBSD::MonitorSIGTRAP() (PR #109643)

[Kelvin Lee via lldb-commits]

https://github.com/kiyolee updated 
https://github.com/llvm/llvm-project/pull/109643

>From 036d7f64d052165d0535d48ef1d52c61d67a7eb2 Mon Sep 17 00:00:00 2001
From: Kelvin Lee 
Date: Mon, 23 Sep 2024 19:43:20 +1000
Subject: [PATCH] [lldb][FreeBSD] Fix a typo in
 NativeProcessFreeBSD::MonitorSIGTRAP()

---
 lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp 
b/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
index 80b27571f43d55..bf552e19742c4a 100644
--- a/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
+++ b/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
@@ -324,7 +324,7 @@ void NativeProcessFreeBSD::MonitorSIGTRAP(lldb::pid_t pid) {
 auto thread_info =
 m_threads_stepping_with_breakpoint.find(thread->GetID());
 if (thread_info != m_threads_stepping_with_breakpoint.end() &&
-threads_info->second == regctx.GetPC()) {
+thread_info->second == regctx.GetPC()) {
   thread->SetStoppedByTrace();
   Status brkpt_error = RemoveBreakpoint(thread_info->second);
   if (brkpt_error.Fail())

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

[Lldb-commits] [lldb] 85220a0 - [lldb][FreeBSD] Fix a typo in NativeProcessFreeBSD::MonitorSIGTRAP() (#109643)

[via lldb-commits]

Author: Kelvin Lee
Date: 2024-09-23T11:44:58+01:00
New Revision: 85220a0c651e565ab576c5be17c1ec5c9eb2a350

URL: 
https://github.com/llvm/llvm-project/commit/85220a0c651e565ab576c5be17c1ec5c9eb2a350
DIFF: 
https://github.com/llvm/llvm-project/commit/85220a0c651e565ab576c5be17c1ec5c9eb2a350.diff

LOG: [lldb][FreeBSD] Fix a typo in NativeProcessFreeBSD::MonitorSIGTRAP() 
(#109643)

Apparently a typo is causing compile error, added by 
https://github.com/llvm/llvm-project/pull/108504.

Added: 


Modified: 
lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp 
b/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
index 80b27571f43d55..bf552e19742c4a 100644
--- a/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
+++ b/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
@@ -324,7 +324,7 @@ void NativeProcessFreeBSD::MonitorSIGTRAP(lldb::pid_t pid) {
 auto thread_info =
 m_threads_stepping_with_breakpoint.find(thread->GetID());
 if (thread_info != m_threads_stepping_with_breakpoint.end() &&
-threads_info->second == regctx.GetPC()) {
+thread_info->second == regctx.GetPC()) {
   thread->SetStoppedByTrace();
   Status brkpt_error = RemoveBreakpoint(thread_info->second);
   if (brkpt_error.Fail())



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

[Lldb-commits] [lldb] [lldb][FreeBSD] Fix a typo in NativeProcessFreeBSD::MonitorSIGTRAP() (PR #109643)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett closed 
https://github.com/llvm/llvm-project/pull/109643
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][FreeBSD] Fix a typo in NativeProcessFreeBSD::MonitorSIGTRAP() (PR #109643)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett approved this pull request.

Caused by https://github.com/llvm/llvm-project/pull/108504.

Thanks for the fix.

https://github.com/llvm/llvm-project/pull/109643
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 6ad268e - [lldb] refactor Target::Install function (#108996)

[via lldb-commits]

Author: dlav-sc
Date: 2024-09-23T08:54:16+01:00
New Revision: 6ad268e3913cb6814fabae420a8e80156e1632a7

URL: 
https://github.com/llvm/llvm-project/commit/6ad268e3913cb6814fabae420a8e80156e1632a7
DIFF: 
https://github.com/llvm/llvm-project/commit/6ad268e3913cb6814fabae420a8e80156e1632a7.diff

LOG: [lldb] refactor Target::Install function (#108996)

refactor Target::Install function

Added: 


Modified: 
lldb/source/Target/Target.cpp

Removed: 




diff  --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index f9b6f7ded267ee..29e9efb83efeb6 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -77,6 +77,80 @@
 using namespace lldb;
 using namespace lldb_private;
 
+namespace {
+
+struct ExecutableInstaller {
+
+  ExecutableInstaller(PlatformSP platform, ModuleSP module)
+  : m_platform{platform}, m_module{module},
+m_local_file{m_module->GetFileSpec()},
+m_remote_file{m_module->GetRemoteInstallFileSpec()} {}
+
+  void setupRemoteFile() const { m_module->SetPlatformFileSpec(m_remote_file); 
}
+
+  PlatformSP m_platform;
+  ModuleSP m_module;
+  const FileSpec m_local_file;
+  const FileSpec m_remote_file;
+};
+
+struct MainExecutableInstaller {
+
+  MainExecutableInstaller(PlatformSP platform, ModuleSP module, TargetSP 
target,
+  ProcessLaunchInfo &launch_info)
+  : m_platform{platform}, m_module{module},
+m_local_file{m_module->GetFileSpec()},
+m_remote_file{
+getRemoteFileSpec(m_platform, target, m_module, m_local_file)},
+m_launch_info{launch_info} {}
+
+  void setupRemoteFile() const {
+m_module->SetPlatformFileSpec(m_remote_file);
+m_launch_info.SetExecutableFile(m_remote_file,
+/*add_exe_file_as_first_arg=*/false);
+m_platform->SetFilePermissions(m_remote_file, 0700 /*-rwx--*/);
+  }
+
+  PlatformSP m_platform;
+  ModuleSP m_module;
+  const FileSpec m_local_file;
+  const FileSpec m_remote_file;
+
+private:
+  static FileSpec getRemoteFileSpec(PlatformSP platform, TargetSP target,
+ModuleSP module,
+const FileSpec &local_file) {
+FileSpec remote_file = module->GetRemoteInstallFileSpec();
+if (remote_file || !target->GetAutoInstallMainExecutable())
+  return remote_file;
+
+if (!local_file)
+  return {};
+
+remote_file = platform->GetRemoteWorkingDirectory();
+remote_file.AppendPathComponent(local_file.GetFilename().GetCString());
+
+return remote_file;
+  }
+
+  ProcessLaunchInfo &m_launch_info;
+};
+} // namespace
+
+template 
+static Status installExecutable(const Installer &installer) {
+  if (!installer.m_local_file || !installer.m_remote_file)
+return Status();
+
+  Status error = installer.m_platform->Install(installer.m_local_file,
+   installer.m_remote_file);
+  if (error.Fail())
+return error;
+
+  installer.setupRemoteFile();
+  return Status();
+}
+
 constexpr std::chrono::milliseconds EvaluateExpressionOptions::default_timeout;
 
 Target::Arch::Arch(const ArchSpec &spec)
@@ -3077,48 +3151,28 @@ TargetProperties &Target::GetGlobalProperties() {
 Status Target::Install(ProcessLaunchInfo *launch_info) {
   Status error;
   PlatformSP platform_sp(GetPlatform());
-  if (platform_sp) {
-if (platform_sp->IsRemote()) {
-  if (platform_sp->IsConnected()) {
-// Install all files that have an install path when connected to a
-// remote platform. If target.auto-install-main-executable is set then
-// also install the main executable even if it does not have an 
explicit
-// install path specified.
-const ModuleList &modules = GetImages();
-const size_t num_images = modules.GetSize();
-for (size_t idx = 0; idx < num_images; ++idx) {
-  ModuleSP module_sp(modules.GetModuleAtIndex(idx));
-  if (module_sp) {
-const bool is_main_executable = module_sp == GetExecutableModule();
-FileSpec local_file(module_sp->GetFileSpec());
-if (local_file) {
-  FileSpec remote_file(module_sp->GetRemoteInstallFileSpec());
-  if (!remote_file) {
-if (is_main_executable && GetAutoInstallMainExecutable()) {
-  // Automatically install the main executable.
-  remote_file = platform_sp->GetRemoteWorkingDirectory();
-  remote_file.AppendPathComponent(
-  module_sp->GetFileSpec().GetFilename().GetCString());
-}
-  }
-  if (remote_file) {
-error = platform_sp->Install(local_file, remote_file);
-if (error.Success()) {
-  module_sp->SetPlatformFileSpec(remote_file);
-  if (is_main_execu

[Lldb-commits] [lldb] [lldb] refactor Target::Install function (PR #108996)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett closed 
https://github.com/llvm/llvm-project/pull/108996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB][Minidump] Have Minidumps save off and properly read TLS data (PR #109477)

[Pavel Labath via lldb-commits]

@@ -333,6 +335,23 @@ ArchSpec ProcessMinidump::GetArchitecture() {
   return ArchSpec(triple);
 }
 
+DynamicLoader *ProcessMinidump::GetDynamicLoader() {
+  if (m_dyld_up.get() == nullptr)
+m_dyld_up.reset(DynamicLoader::FindPlugin(
+this, DynamicLoaderPOSIXDYLD::GetPluginNameStatic()));

labath wrote:

The dynamic loader choice will only be correct linux (and other elf systems). 
How about we drop this override to get the default behavior?

https://github.com/llvm/llvm-project/pull/109477
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB][Minidump] Have Minidumps save off and properly read TLS data (PR #109477)

[Pavel Labath via lldb-commits]

@@ -6528,6 +6528,74 @@ static void AddRegion(const MemoryRegionInfo ®ion, 
bool try_dirty_pages,
 CreateCoreFileMemoryRange(region));
 }
 
+static void AddRegisterSections(Process &process, ThreadSP &thread_sp,
+CoreFileMemoryRanges &ranges,
+lldb::addr_t range_end) {
+  lldb::RegisterContextSP reg_ctx = thread_sp->GetRegisterContext();
+  if (!reg_ctx)
+return;
+
+  const RegisterInfo *reg_info = reg_ctx->GetRegisterInfo(
+  lldb::RegisterKind::eRegisterKindGeneric, LLDB_REGNUM_GENERIC_TP);
+  if (!reg_info)
+return;
+
+  lldb_private::RegisterValue reg_value;
+  bool success = reg_ctx->ReadRegister(reg_info, reg_value);
+  if (!success)
+return;
+
+  const uint64_t fail_value = UINT64_MAX;
+  bool readSuccess = false;
+  const lldb::addr_t reg_value_addr =
+  reg_value.GetAsUInt64(fail_value, &readSuccess);
+  if (!readSuccess || reg_value_addr == fail_value)
+return;
+
+  MemoryRegionInfo register_region;
+  Status err = process.GetMemoryRegionInfo(reg_value_addr, register_region);
+  if (err.Fail())
+return;
+
+  // We already saved off this truncated stack range.
+  if (register_region.GetRange().GetRangeEnd() == range_end)
+return;
+
+  // We don't need to worry about duplication because the CoreFileMemoryRanges
+  // will unique them
+  AddRegion(register_region, true, ranges);
+}
+
+static void AddModuleSections(Process &process, CoreFileMemoryRanges &ranges,
+  std::set &stack_ends) {
+  ModuleList &module_list = process.GetTarget().GetImages();
+  Target *target = &process.GetTarget();
+  for (size_t idx = 0; idx < module_list.GetSize(); idx++) {
+ModuleSP module_sp = module_list.GetModuleAtIndex(idx);
+if (!module_sp)
+  continue;
+
+ObjectFile *obj = module_sp->GetObjectFile();
+if (!obj)
+  continue;
+Address addr = obj->GetImageInfoAddress(target);
+addr_t load_addr = addr.GetLoadAddress(target);
+if (load_addr == LLDB_INVALID_ADDRESS)
+  continue;
+
+MemoryRegionInfo tls_storage_region;
+Status err = process.GetMemoryRegionInfo(load_addr, tls_storage_region);

labath wrote:

IIUC, this is saving the (dynamic) link map. What has it got to do with TLS?

https://github.com/llvm/llvm-project/pull/109477
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB][Minidump] Have Minidumps save off and properly read TLS data (PR #109477)

[Pavel Labath via lldb-commits]

https://github.com/labath edited 
https://github.com/llvm/llvm-project/pull/109477
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB][Minidump] Have Minidumps save off and properly read TLS data (PR #109477)

[Pavel Labath via lldb-commits]

https://github.com/labath commented:

It may be best to separate the loading and saving parts into separate PRs, as 
the two are functionality separate. (and I have -- separate -- questions about 
each part).

For loading, I'd like to discuss the back door you're adding DidAttach 
function. The thing I don't like there is that this is already a sort of a back 
door added in http://reviews.llvm.org/D9471 to support "processes which can 
load their own libraries". Here we have a process "that loads its own 
libraries" (that's how it was able to get away without a dynamic loader so 
far), *but* which does want the loader plugin to do some loading as well (What 
exactly is the thing that's missing due to this check? Is it that 
`m_loaded_modules` does not get populated?).

Instead of poking holes in that check, I'd like to see if we can reduce the 
scope of the original patch, as it seems to have been added in support of a 
very specific use case. So specific that I can't even think of what it was -- 
the patch is light on specifics, and I don't know of any gdb server that 
`qxfer:libraries` (as opposed to `qxfer:libraries-svr4`) *and* the "posix" 
dynamic loader plugin.

If we can't come up with a good solution with reasonable effort, then I'd be 
willing to even reduce its scope to zero (effectively revert that part of the 
patch), as we should not be carrying (untested?) code which we don't 
understand, particularly when it causes problems (I doubt the author of that 
patch tested TLS, but your PR shows that it does not work this way, and I also 
remember having problems with these lines of code in the past).

For the second part of the patch (saving minidumps) I'd like to better 
understand what it is that you're saving with this code. In particular, I'm 
confused as to how we can save TLS by iterating over the modules (alone). For 
the most general (general dynamic tls model) case, I think you'd need a 
(thread`x`module) nested loop since `dlopen`ed shared libraries may have their 
TLS allocated in a random piece of memory by malloc (TLS is 
[very](https://maskray.me/blog/2021-02-14-all-about-thread-local-storage) 
complicated). Instead of trying to piece it together generically (the thread 
register is just the beginning) it may be better to ask the dynamic linker 
plugin to provide the list of memory regions that (may) contain the TLS data.

https://github.com/llvm/llvm-project/pull/109477
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Don't invalid register context after setting thread pc's (PR #109499)

[Pavel Labath via lldb-commits]

labath wrote:

What's the exact situation that triggered these extra packets. Could it be 
simulated from a gdb-remote client test (i.e., by mocking server responses)?

https://github.com/llvm/llvm-project/pull/109499
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

[Michael Buch via lldb-commits]

@@ -0,0 +1,94 @@
+# Adding Programming Language Support
+
+LLDB has been architected to make it straightforward to add support for a
+programming language. Only a small enum in core LLDB needs to be modified to
+make LLDB aware of a new programming language. Everything else can be supplied
+in derived classes that need not even be present in the core LLDB repository.
+This makes it convenient for developers adding language support in downstream
+repositories since it practically eliminates the potential for merge conflicts.
+
+The basic steps are:
+* Add the language to the `LanguageType` enum.
+* Add a `TypeSystem` for the language.
+* Add expression evaluation support.
+
+Additionally, you may want to create a `Language` and `LanguageRuntime` plugin
+for your language, which enables support for advanced features like dynamic
+typing and data formatting.
+
+## Add the Language to the LanguageType enum
+
+The `LanguageType` enum
+(see 
[lldb-enumerations.h](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/lldb-enumerations.h))
+contains a list of every language known to LLDB. It is the one place where
+support for a language must live that will need to merge cleanly with upstream
+LLDB if you are developing your language support in a separate branch. When
+adding support for a language previously unknown to LLDB, start by adding an
+enumeration entry to `LanguageType`.
+
+## Add a TypeSystem for the Language
+
+Both 
[Module](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Core/Module.h)
+and 
[Target](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Target/Target.h)
+support the retrieval of a `TypeSystem` instance via 
`GetTypeSystemForLanguage()`.
+For `Module`, this method is directly on the `Module` instance. For `Target`,
+this is retrieved indirectly via the `TypeSystemMap` for the `Target` instance.
+
+The `TypeSystem` instance returned by the `Target` is expected to be capable of
+evaluating expressions, while the `TypeSystem` instance returned by the 
`Module`
+is not. If want to support expression evaluation for your language, you could
+consider one of the following approaches:
+* Implement a single `TypeSystem` class that supports evaluation when given an
+  optional `Target`, implementing all the expression evaluation methods on the
+  `TypeSystem`.
+* Create multiple `TypeSystem` classes, one for evaluation and one for static
+  `Module` usage.
+
+For clang and Swift, the latter approach was chosen. Primarily to make it
+clearer that evaluation with the static `Module`-returned `TypeSystem` 
instances
+make no sense, and have them error out on those calls. But either approach is
+fine.
+
+# Add Expression Evaluation Support
+
+Expression Evaluation support is enabled by implementing the relevant methods 
on
+a `TypeSystem`-derived class. Search for `Expression` in the
+[TypeSystem 
header](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Symbol/TypeSystem.h)
+to find the methods to implement.
+
+# Type Completion
+
+There are three levels of type completion, each requiring more type 
information:

Michael137 wrote:

Since you're just reviving the documentation, happy to keep it as is and clean 
it up later.

I'm not sure there's a ton of actionable info in this section for someone 
trying to add new language support. `Pointer size`/`Layout info`/`Full type 
info` don't correspond to specific constructs that one could grep for (AFAIK). 
I assume this is talking about 
`ResolveState::Forward`/`ResolveState::Layout`/`ResolveState::Full`? And the 
recommendation here is to create `Forward` `CompilerType`s where possible? 
(Technically `Layout` resolve state will pull in the full type definition. The 
only distinction between fully resolving vs. layout resolving a type is that it 
won't try to fully complete a pointee type, but I guess that's kind of an 
implementation detail not worth pointing out?).

Also, would it make sense to move it after `Creating Types` (or make it a 
subsection)? Because we just start talking about "types" without having 
mentioned them before.

Side-note, I have been documenting a lot of the type-completion/expression 
evaluation infrastructure internally, and intend to upstream it at some point. 
So this would be a natural place to put it.

https://github.com/llvm/llvm-project/pull/109427
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

[Michael Buch via lldb-commits]

@@ -0,0 +1,94 @@
+# Adding Programming Language Support
+
+LLDB has been architected to make it straightforward to add support for a
+programming language. Only a small enum in core LLDB needs to be modified to
+make LLDB aware of a new programming language. Everything else can be supplied
+in derived classes that need not even be present in the core LLDB repository.
+This makes it convenient for developers adding language support in downstream
+repositories since it practically eliminates the potential for merge conflicts.
+
+The basic steps are:
+* Add the language to the `LanguageType` enum.
+* Add a `TypeSystem` for the language.
+* Add expression evaluation support.
+
+Additionally, you may want to create a `Language` and `LanguageRuntime` plugin
+for your language, which enables support for advanced features like dynamic
+typing and data formatting.
+
+## Add the Language to the LanguageType enum
+
+The `LanguageType` enum
+(see 
[lldb-enumerations.h](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/lldb-enumerations.h))
+contains a list of every language known to LLDB. It is the one place where
+support for a language must live that will need to merge cleanly with upstream
+LLDB if you are developing your language support in a separate branch. When
+adding support for a language previously unknown to LLDB, start by adding an
+enumeration entry to `LanguageType`.
+
+## Add a TypeSystem for the Language
+
+Both 
[Module](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Core/Module.h)
+and 
[Target](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Target/Target.h)
+support the retrieval of a `TypeSystem` instance via 
`GetTypeSystemForLanguage()`.
+For `Module`, this method is directly on the `Module` instance. For `Target`,
+this is retrieved indirectly via the `TypeSystemMap` for the `Target` instance.
+
+The `TypeSystem` instance returned by the `Target` is expected to be capable of
+evaluating expressions, while the `TypeSystem` instance returned by the 
`Module`
+is not. If want to support expression evaluation for your language, you could

Michael137 wrote:

```suggestion
is not. If you want to support expression evaluation for your language, you 
could
```

https://github.com/llvm/llvm-project/pull/109427
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett updated 
https://github.com/llvm/llvm-project/pull/109427

>From cc4032e58217a01ff414b8d03866a1631f492df8 Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Fri, 20 Sep 2024 14:00:44 +0100
Subject: [PATCH 1/3] [lldb][docs] Resurrect the information on adding a new
 language

This got deleted in e078c9507c3abb4d9bb2265c366b26557880a3e3,
I presume accidentally, because it didn't have a corresponding rst
file for it.

So I've brought it back and converted it into Markdown. The content
remains accurate, from what I know at least.

It's a bit "now draw the rest of the owl" but if nothing else,
it gives you a bunch of important classes to go and research
as a starting point.

You can see the original content here:
https://github.com/llvm/llvm-project/blob/5d71fc5d7b5ffe2323418a09db6eddaf84d6c662/lldb/www/adding-language-support.html
---
 lldb/docs/index.rst  |  1 +
 lldb/docs/resources/addinglanguagesupport.md | 95 
 2 files changed, 96 insertions(+)
 create mode 100644 lldb/docs/resources/addinglanguagesupport.md

diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index d9b8e589eb2ac0..dd44a8430add80 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -163,6 +163,7 @@ interesting areas to contribute to lldb.
resources/caveats
resources/projects
resources/lldbdap
+   resources/addinglanguagesupport
Public C++ API 
Private C++ API 
 
diff --git a/lldb/docs/resources/addinglanguagesupport.md 
b/lldb/docs/resources/addinglanguagesupport.md
new file mode 100644
index 00..d92104a0e5e6ec
--- /dev/null
+++ b/lldb/docs/resources/addinglanguagesupport.md
@@ -0,0 +1,95 @@
+# Adding Programming Language Support
+
+LLDB has been architected to make it straightforward to add support for a
+programming language. Only a small enum in core LLDB needs to be modified to
+make LLDB aware of a new programming language. Everything else can be supplied
+in derived classes that need not even be present in the core LLDB repository.
+This makes it convenient for developers adding language support either in
+branches or downstream repositories since it practically eliminates the
+potential for merge conflicts.
+
+The basic steps are:
+* Add the language to the `LanguageType` enum.
+* Add a `TypeSystem` for the language.
+* Add expression evaluation support.
+
+Additionally, you may want to create a `Language` and `LanguageRuntime` plugin
+for your language, which enables support for advanced features like dynamic
+typing and data formatting.
+
+## Add the Language to the LanguageType enum
+
+The `LanguageType` enum
+(see 
[lldb-enumerations.h](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/lldb-enumerations.h))
+contains a list of every language known to LLDB. It is the one place where
+support for a language must live that will need to merge cleanly with upstream
+LLDB if you are developing your language support in a separate branch. When
+adding support for a language previously unknown to LLDB, start by adding an
+enumeration entry to `LanguageType`.
+
+## Add a TypeSystem for the Language
+
+Both 
[Module](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Core/Module.h)
+and 
[Target](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Target/Target.h)
+support the retrieval of a `TypeSystem` instance via 
`GetTypeSystemForLanguage()`.
+For `Module`, this method is directly on the `Module` instance. For `Target`,
+this is retrieved indirectly via the `TypeSystemMap` for the `Target` instance.
+
+The `TypeSystem` instance returned by the `Target` is expected to be capable of
+evaluating expressions, while the `TypeSystem` instance returned by the 
`Module`
+is not. If want to support expression evaluation for your language, you could
+consider one of the following approaches:
+* Implement a single `TypeSystem` class that supports evaluation when given an
+  optional `Target`, implementing all the expression evaluation methods on the
+  `TypeSystem`.
+* Create multiple `TypeSystem` classes, one for evaluation and one for static
+  `Module` usage.
+
+For clang and Swift, the latter approach was chosen. Primarily to make it
+clearer that evaluation with the static `Module`-returned `TypeSystem` 
instances
+make no sense, and have them error out on those calls. But either approach is
+fine.
+
+# Add Expression Evaluation Support
+
+Expression Evaluation support is enabled by implementing the relevant methods 
on
+a `TypeSystem`-derived class. Search for `Expression` in the
+[TypeSystem 
header](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Symbol/TypeSystem.h)
+to find the methods to implement.
+
+# Type Completion
+
+There are three levels of type completion, each requiring more type 
information:
+1. Pointer size: When you have a forward decl or a

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

[David Spickett via lldb-commits]

@@ -0,0 +1,94 @@
+# Adding Programming Language Support
+
+LLDB has been architected to make it straightforward to add support for a
+programming language. Only a small enum in core LLDB needs to be modified to
+make LLDB aware of a new programming language. Everything else can be supplied
+in derived classes that need not even be present in the core LLDB repository.
+This makes it convenient for developers adding language support in downstream
+repositories since it practically eliminates the potential for merge conflicts.
+
+The basic steps are:
+* Add the language to the `LanguageType` enum.
+* Add a `TypeSystem` for the language.
+* Add expression evaluation support.
+
+Additionally, you may want to create a `Language` and `LanguageRuntime` plugin
+for your language, which enables support for advanced features like dynamic
+typing and data formatting.
+
+## Add the Language to the LanguageType enum
+
+The `LanguageType` enum
+(see 
[lldb-enumerations.h](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/lldb-enumerations.h))
+contains a list of every language known to LLDB. It is the one place where
+support for a language must live that will need to merge cleanly with upstream
+LLDB if you are developing your language support in a separate branch. When
+adding support for a language previously unknown to LLDB, start by adding an
+enumeration entry to `LanguageType`.
+
+## Add a TypeSystem for the Language
+
+Both 
[Module](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Core/Module.h)
+and 
[Target](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Target/Target.h)
+support the retrieval of a `TypeSystem` instance via 
`GetTypeSystemForLanguage()`.
+For `Module`, this method is directly on the `Module` instance. For `Target`,
+this is retrieved indirectly via the `TypeSystemMap` for the `Target` instance.
+
+The `TypeSystem` instance returned by the `Target` is expected to be capable of
+evaluating expressions, while the `TypeSystem` instance returned by the 
`Module`
+is not. If want to support expression evaluation for your language, you could
+consider one of the following approaches:
+* Implement a single `TypeSystem` class that supports evaluation when given an
+  optional `Target`, implementing all the expression evaluation methods on the
+  `TypeSystem`.
+* Create multiple `TypeSystem` classes, one for evaluation and one for static
+  `Module` usage.
+
+For clang and Swift, the latter approach was chosen. Primarily to make it
+clearer that evaluation with the static `Module`-returned `TypeSystem` 
instances
+make no sense, and have them error out on those calls. But either approach is
+fine.
+
+# Add Expression Evaluation Support
+
+Expression Evaluation support is enabled by implementing the relevant methods 
on
+a `TypeSystem`-derived class. Search for `Expression` in the
+[TypeSystem 
header](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Symbol/TypeSystem.h)
+to find the methods to implement.
+
+# Type Completion
+
+There are three levels of type completion, each requiring more type 
information:

DavidSpickett wrote:

Yes, I haven't done this stuff before (I just looked into this for Fortran a 
bit) so you're probably right.

(also it sounds like you are best placed to write the replacement content :) )

https://github.com/llvm/llvm-project/pull/109427
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

[David Spickett via lldb-commits]

@@ -0,0 +1,94 @@
+# Adding Programming Language Support
+
+LLDB has been architected to make it straightforward to add support for a
+programming language. Only a small enum in core LLDB needs to be modified to
+make LLDB aware of a new programming language. Everything else can be supplied
+in derived classes that need not even be present in the core LLDB repository.
+This makes it convenient for developers adding language support in downstream
+repositories since it practically eliminates the potential for merge conflicts.
+
+The basic steps are:
+* Add the language to the `LanguageType` enum.
+* Add a `TypeSystem` for the language.
+* Add expression evaluation support.
+
+Additionally, you may want to create a `Language` and `LanguageRuntime` plugin
+for your language, which enables support for advanced features like dynamic
+typing and data formatting.
+
+## Add the Language to the LanguageType enum
+
+The `LanguageType` enum
+(see 
[lldb-enumerations.h](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/lldb-enumerations.h))
+contains a list of every language known to LLDB. It is the one place where
+support for a language must live that will need to merge cleanly with upstream
+LLDB if you are developing your language support in a separate branch. When
+adding support for a language previously unknown to LLDB, start by adding an
+enumeration entry to `LanguageType`.
+
+## Add a TypeSystem for the Language
+
+Both 
[Module](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Core/Module.h)
+and 
[Target](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Target/Target.h)
+support the retrieval of a `TypeSystem` instance via 
`GetTypeSystemForLanguage()`.
+For `Module`, this method is directly on the `Module` instance. For `Target`,
+this is retrieved indirectly via the `TypeSystemMap` for the `Target` instance.
+
+The `TypeSystem` instance returned by the `Target` is expected to be capable of
+evaluating expressions, while the `TypeSystem` instance returned by the 
`Module`
+is not. If want to support expression evaluation for your language, you could
+consider one of the following approaches:
+* Implement a single `TypeSystem` class that supports evaluation when given an
+  optional `Target`, implementing all the expression evaluation methods on the
+  `TypeSystem`.
+* Create multiple `TypeSystem` classes, one for evaluation and one for static
+  `Module` usage.
+
+For clang and Swift, the latter approach was chosen. Primarily to make it
+clearer that evaluation with the static `Module`-returned `TypeSystem` 
instances
+make no sense, and have them error out on those calls. But either approach is
+fine.
+
+# Add Expression Evaluation Support
+
+Expression Evaluation support is enabled by implementing the relevant methods 
on
+a `TypeSystem`-derived class. Search for `Expression` in the
+[TypeSystem 
header](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Symbol/TypeSystem.h)
+to find the methods to implement.
+
+# Type Completion
+
+There are three levels of type completion, each requiring more type 
information:

DavidSpickett wrote:

I've moved the section up.

We could just remove it, if it's something folks will naturally find out as 
they do their implementation.

https://github.com/llvm/llvm-project/pull/109427
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [lldb] [AMDGPU] Specify width and align for all AMDGPU builtin types. NFC. (PR #109656)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-clang-codegen

Author: Jay Foad (jayfoad)


Changes

This will be used in ASTContext::getTypeInfo which needs this
information for all builtin types, not just pointers.


---

Patch is 20.84 KiB, truncated to 20.00 KiB below, full version: 
https://github.com/llvm/llvm-project/pull/109656.diff


25 Files Affected:

- (modified) clang/include/clang/AST/ASTContext.h (+2-1) 
- (modified) clang/include/clang/AST/Type.h (+1-1) 
- (modified) clang/include/clang/AST/TypeProperties.td (+1-1) 
- (modified) clang/include/clang/Basic/AMDGPUTypes.def (+3-3) 
- (modified) clang/include/clang/Serialization/ASTBitCodes.h (+1-1) 
- (modified) clang/lib/AST/ASTContext.cpp (+4-4) 
- (modified) clang/lib/AST/ASTImporter.cpp (+1-1) 
- (modified) clang/lib/AST/ExprConstant.cpp (+1-1) 
- (modified) clang/lib/AST/ItaniumMangle.cpp (+1-1) 
- (modified) clang/lib/AST/MicrosoftMangle.cpp (+1-1) 
- (modified) clang/lib/AST/NSAPI.cpp (+1-1) 
- (modified) clang/lib/AST/PrintfFormatString.cpp (+1-1) 
- (modified) clang/lib/AST/Type.cpp (+2-2) 
- (modified) clang/lib/AST/TypeLoc.cpp (+1-1) 
- (modified) clang/lib/CodeGen/CGDebugInfo.cpp (+1-1) 
- (modified) clang/lib/CodeGen/CGDebugInfo.h (+2-1) 
- (modified) clang/lib/CodeGen/CodeGenTypes.cpp (+1-1) 
- (modified) clang/lib/CodeGen/ItaniumCXXABI.cpp (+1-1) 
- (modified) clang/lib/Index/USRGeneration.cpp (+1-1) 
- (modified) clang/lib/Sema/Sema.cpp (+1-1) 
- (modified) clang/lib/Sema/SemaExpr.cpp (+2-2) 
- (modified) clang/lib/Serialization/ASTCommon.cpp (+1-1) 
- (modified) clang/lib/Serialization/ASTReader.cpp (+1-1) 
- (modified) clang/tools/libclang/CIndex.cpp (+1-1) 
- (modified) lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp (+2-1) 


``diff
diff --git a/clang/include/clang/AST/ASTContext.h 
b/clang/include/clang/AST/ASTContext.h
index 1984310df0442e..f46e12a57d4c38 100644
--- a/clang/include/clang/AST/ASTContext.h
+++ b/clang/include/clang/AST/ASTContext.h
@@ -1197,7 +1197,8 @@ class ASTContext : public RefCountedBase {
 #include "clang/Basic/RISCVVTypes.def"
 #define WASM_TYPE(Name, Id, SingletonId) CanQualType SingletonId;
 #include "clang/Basic/WebAssemblyReferenceTypes.def"
-#define AMDGPU_TYPE(Name, Id, SingletonId) CanQualType SingletonId;
+#define AMDGPU_TYPE(Name, Id, SingletonId, Width, Align)   
\
+  CanQualType SingletonId;
 #include "clang/Basic/AMDGPUTypes.def"
 #define HLSL_INTANGIBLE_TYPE(Name, Id, SingletonId) CanQualType SingletonId;
 #include "clang/Basic/HLSLIntangibleTypes.def"
diff --git a/clang/include/clang/AST/Type.h b/clang/include/clang/AST/Type.h
index dc87b84153e74a..cee4e68fe0dc6d 100644
--- a/clang/include/clang/AST/Type.h
+++ b/clang/include/clang/AST/Type.h
@@ -3050,7 +3050,7 @@ class BuiltinType : public Type {
 #define WASM_TYPE(Name, Id, SingletonId) Id,
 #include "clang/Basic/WebAssemblyReferenceTypes.def"
 // AMDGPU types
-#define AMDGPU_TYPE(Name, Id, SingletonId) Id,
+#define AMDGPU_TYPE(Name, Id, SingletonId, Width, Align) Id,
 #include "clang/Basic/AMDGPUTypes.def"
 // HLSL intangible Types
 #define HLSL_INTANGIBLE_TYPE(Name, Id, SingletonId) Id,
diff --git a/clang/include/clang/AST/TypeProperties.td 
b/clang/include/clang/AST/TypeProperties.td
index bb7bfa8cd0b76e..d05072607e949c 100644
--- a/clang/include/clang/AST/TypeProperties.td
+++ b/clang/include/clang/AST/TypeProperties.td
@@ -893,7 +893,7 @@ let Class = BuiltinType in {
   case BuiltinType::ID: return ctx.SINGLETON_ID;
 #include "clang/Basic/WebAssemblyReferenceTypes.def"
 
-#define AMDGPU_TYPE(NAME, ID, SINGLETON_ID) \
+#define AMDGPU_TYPE(NAME, ID, SINGLETON_ID, WIDTH, ALIGN) \
   case BuiltinType::ID: return ctx.SINGLETON_ID;
 #include "clang/Basic/AMDGPUTypes.def"
 
diff --git a/clang/include/clang/Basic/AMDGPUTypes.def 
b/clang/include/clang/Basic/AMDGPUTypes.def
index 7454d61f5dd516..e47e544fdc82c1 100644
--- a/clang/include/clang/Basic/AMDGPUTypes.def
+++ b/clang/include/clang/Basic/AMDGPUTypes.def
@@ -11,11 +11,11 @@
 
//===--===//
 
 #ifndef AMDGPU_OPAQUE_PTR_TYPE
-#define AMDGPU_OPAQUE_PTR_TYPE(Name, AS, Width, Align, Id, SingletonId) \
-  AMDGPU_TYPE(Name, Id, SingletonId)
+#define AMDGPU_OPAQUE_PTR_TYPE(Name, Id, SingletonId, Width, Align, AS) \
+  AMDGPU_TYPE(Name, Id, SingletonId, Width, Align)
 #endif
 
-AMDGPU_OPAQUE_PTR_TYPE("__amdgpu_buffer_rsrc_t", 8, 128, 128, 
AMDGPUBufferRsrc, AMDGPUBufferRsrcTy)
+AMDGPU_OPAQUE_PTR_TYPE("__amdgpu_buffer_rsrc_t", AMDGPUBufferRsrc, 
AMDGPUBufferRsrcTy, 128, 128, 8)
 
 #undef AMDGPU_TYPE
 #undef AMDGPU_OPAQUE_PTR_TYPE
diff --git a/clang/include/clang/Serialization/ASTBitCodes.h 
b/clang/include/clang/Serialization/ASTBitCodes.h
index 4410df296d8efc..8c29f8c0ae5f55 100644
--- a/clang/include/clang/Serialization/ASTBitCodes.h
+++ b/clang/include/clang/Serialization/ASTBitCodes.h
@@ -1122,7 +1122,7 @@ enum PredefinedTypeIDs {
 #define WASM_TYPE(Name, Id, SingletonId) PREDEF_TYPE_

[Lldb-commits] [clang] [lldb] [AMDGPU] Specify width and align for all AMDGPU builtin types. NFC. (PR #109656)

[via lldb-commits]

llvmbot wrote:



@llvm/pr-subscribers-clang-modules
@llvm/pr-subscribers-debuginfo

@llvm/pr-subscribers-lldb

Author: Jay Foad (jayfoad)


Changes

This will be used in ASTContext::getTypeInfo which needs this
information for all builtin types, not just pointers.


---

Patch is 20.84 KiB, truncated to 20.00 KiB below, full version: 
https://github.com/llvm/llvm-project/pull/109656.diff


25 Files Affected:

- (modified) clang/include/clang/AST/ASTContext.h (+2-1) 
- (modified) clang/include/clang/AST/Type.h (+1-1) 
- (modified) clang/include/clang/AST/TypeProperties.td (+1-1) 
- (modified) clang/include/clang/Basic/AMDGPUTypes.def (+3-3) 
- (modified) clang/include/clang/Serialization/ASTBitCodes.h (+1-1) 
- (modified) clang/lib/AST/ASTContext.cpp (+4-4) 
- (modified) clang/lib/AST/ASTImporter.cpp (+1-1) 
- (modified) clang/lib/AST/ExprConstant.cpp (+1-1) 
- (modified) clang/lib/AST/ItaniumMangle.cpp (+1-1) 
- (modified) clang/lib/AST/MicrosoftMangle.cpp (+1-1) 
- (modified) clang/lib/AST/NSAPI.cpp (+1-1) 
- (modified) clang/lib/AST/PrintfFormatString.cpp (+1-1) 
- (modified) clang/lib/AST/Type.cpp (+2-2) 
- (modified) clang/lib/AST/TypeLoc.cpp (+1-1) 
- (modified) clang/lib/CodeGen/CGDebugInfo.cpp (+1-1) 
- (modified) clang/lib/CodeGen/CGDebugInfo.h (+2-1) 
- (modified) clang/lib/CodeGen/CodeGenTypes.cpp (+1-1) 
- (modified) clang/lib/CodeGen/ItaniumCXXABI.cpp (+1-1) 
- (modified) clang/lib/Index/USRGeneration.cpp (+1-1) 
- (modified) clang/lib/Sema/Sema.cpp (+1-1) 
- (modified) clang/lib/Sema/SemaExpr.cpp (+2-2) 
- (modified) clang/lib/Serialization/ASTCommon.cpp (+1-1) 
- (modified) clang/lib/Serialization/ASTReader.cpp (+1-1) 
- (modified) clang/tools/libclang/CIndex.cpp (+1-1) 
- (modified) lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp (+2-1) 


``diff
diff --git a/clang/include/clang/AST/ASTContext.h 
b/clang/include/clang/AST/ASTContext.h
index 1984310df0442e..f46e12a57d4c38 100644
--- a/clang/include/clang/AST/ASTContext.h
+++ b/clang/include/clang/AST/ASTContext.h
@@ -1197,7 +1197,8 @@ class ASTContext : public RefCountedBase {
 #include "clang/Basic/RISCVVTypes.def"
 #define WASM_TYPE(Name, Id, SingletonId) CanQualType SingletonId;
 #include "clang/Basic/WebAssemblyReferenceTypes.def"
-#define AMDGPU_TYPE(Name, Id, SingletonId) CanQualType SingletonId;
+#define AMDGPU_TYPE(Name, Id, SingletonId, Width, Align)   
\
+  CanQualType SingletonId;
 #include "clang/Basic/AMDGPUTypes.def"
 #define HLSL_INTANGIBLE_TYPE(Name, Id, SingletonId) CanQualType SingletonId;
 #include "clang/Basic/HLSLIntangibleTypes.def"
diff --git a/clang/include/clang/AST/Type.h b/clang/include/clang/AST/Type.h
index dc87b84153e74a..cee4e68fe0dc6d 100644
--- a/clang/include/clang/AST/Type.h
+++ b/clang/include/clang/AST/Type.h
@@ -3050,7 +3050,7 @@ class BuiltinType : public Type {
 #define WASM_TYPE(Name, Id, SingletonId) Id,
 #include "clang/Basic/WebAssemblyReferenceTypes.def"
 // AMDGPU types
-#define AMDGPU_TYPE(Name, Id, SingletonId) Id,
+#define AMDGPU_TYPE(Name, Id, SingletonId, Width, Align) Id,
 #include "clang/Basic/AMDGPUTypes.def"
 // HLSL intangible Types
 #define HLSL_INTANGIBLE_TYPE(Name, Id, SingletonId) Id,
diff --git a/clang/include/clang/AST/TypeProperties.td 
b/clang/include/clang/AST/TypeProperties.td
index bb7bfa8cd0b76e..d05072607e949c 100644
--- a/clang/include/clang/AST/TypeProperties.td
+++ b/clang/include/clang/AST/TypeProperties.td
@@ -893,7 +893,7 @@ let Class = BuiltinType in {
   case BuiltinType::ID: return ctx.SINGLETON_ID;
 #include "clang/Basic/WebAssemblyReferenceTypes.def"
 
-#define AMDGPU_TYPE(NAME, ID, SINGLETON_ID) \
+#define AMDGPU_TYPE(NAME, ID, SINGLETON_ID, WIDTH, ALIGN) \
   case BuiltinType::ID: return ctx.SINGLETON_ID;
 #include "clang/Basic/AMDGPUTypes.def"
 
diff --git a/clang/include/clang/Basic/AMDGPUTypes.def 
b/clang/include/clang/Basic/AMDGPUTypes.def
index 7454d61f5dd516..e47e544fdc82c1 100644
--- a/clang/include/clang/Basic/AMDGPUTypes.def
+++ b/clang/include/clang/Basic/AMDGPUTypes.def
@@ -11,11 +11,11 @@
 
//===--===//
 
 #ifndef AMDGPU_OPAQUE_PTR_TYPE
-#define AMDGPU_OPAQUE_PTR_TYPE(Name, AS, Width, Align, Id, SingletonId) \
-  AMDGPU_TYPE(Name, Id, SingletonId)
+#define AMDGPU_OPAQUE_PTR_TYPE(Name, Id, SingletonId, Width, Align, AS) \
+  AMDGPU_TYPE(Name, Id, SingletonId, Width, Align)
 #endif
 
-AMDGPU_OPAQUE_PTR_TYPE("__amdgpu_buffer_rsrc_t", 8, 128, 128, 
AMDGPUBufferRsrc, AMDGPUBufferRsrcTy)
+AMDGPU_OPAQUE_PTR_TYPE("__amdgpu_buffer_rsrc_t", AMDGPUBufferRsrc, 
AMDGPUBufferRsrcTy, 128, 128, 8)
 
 #undef AMDGPU_TYPE
 #undef AMDGPU_OPAQUE_PTR_TYPE
diff --git a/clang/include/clang/Serialization/ASTBitCodes.h 
b/clang/include/clang/Serialization/ASTBitCodes.h
index 4410df296d8efc..8c29f8c0ae5f55 100644
--- a/clang/include/clang/Serialization/ASTBitCodes.h
+++ b/clang/include/clang/Serialization/ASTBitCodes.h
@@ -1122,7 +1122,7 @@ enum PredefinedTypeIDs

[Lldb-commits] [clang] [lldb] [AMDGPU] Specify width and align for all AMDGPU builtin types. NFC. (PR #109656)

[Jay Foad via lldb-commits]

https://github.com/jayfoad created 
https://github.com/llvm/llvm-project/pull/109656

This will be used in ASTContext::getTypeInfo which needs this
information for all builtin types, not just pointers.


>From 0ef4ea17a711a1ee95080bc1635ae9aa824df596 Mon Sep 17 00:00:00 2001
From: Jay Foad 
Date: Tue, 17 Sep 2024 15:06:41 +0100
Subject: [PATCH] [AMDGPU] Specify width and align for all AMDGPU builtin
 types. NFC.

This will be used in ASTContext::getTypeInfo which needs this
information for all builtin types, not just pointers.
---
 clang/include/clang/AST/ASTContext.h | 3 ++-
 clang/include/clang/AST/Type.h   | 2 +-
 clang/include/clang/AST/TypeProperties.td| 2 +-
 clang/include/clang/Basic/AMDGPUTypes.def| 6 +++---
 clang/include/clang/Serialization/ASTBitCodes.h  | 2 +-
 clang/lib/AST/ASTContext.cpp | 8 
 clang/lib/AST/ASTImporter.cpp| 2 +-
 clang/lib/AST/ExprConstant.cpp   | 2 +-
 clang/lib/AST/ItaniumMangle.cpp  | 2 +-
 clang/lib/AST/MicrosoftMangle.cpp| 2 +-
 clang/lib/AST/NSAPI.cpp  | 2 +-
 clang/lib/AST/PrintfFormatString.cpp | 2 +-
 clang/lib/AST/Type.cpp   | 4 ++--
 clang/lib/AST/TypeLoc.cpp| 2 +-
 clang/lib/CodeGen/CGDebugInfo.cpp| 2 +-
 clang/lib/CodeGen/CGDebugInfo.h  | 3 ++-
 clang/lib/CodeGen/CodeGenTypes.cpp   | 2 +-
 clang/lib/CodeGen/ItaniumCXXABI.cpp  | 2 +-
 clang/lib/Index/USRGeneration.cpp| 2 +-
 clang/lib/Sema/Sema.cpp  | 2 +-
 clang/lib/Sema/SemaExpr.cpp  | 4 ++--
 clang/lib/Serialization/ASTCommon.cpp| 2 +-
 clang/lib/Serialization/ASTReader.cpp| 2 +-
 clang/tools/libclang/CIndex.cpp  | 2 +-
 lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp | 3 ++-
 25 files changed, 35 insertions(+), 32 deletions(-)

diff --git a/clang/include/clang/AST/ASTContext.h 
b/clang/include/clang/AST/ASTContext.h
index 1984310df0442e..f46e12a57d4c38 100644
--- a/clang/include/clang/AST/ASTContext.h
+++ b/clang/include/clang/AST/ASTContext.h
@@ -1197,7 +1197,8 @@ class ASTContext : public RefCountedBase {
 #include "clang/Basic/RISCVVTypes.def"
 #define WASM_TYPE(Name, Id, SingletonId) CanQualType SingletonId;
 #include "clang/Basic/WebAssemblyReferenceTypes.def"
-#define AMDGPU_TYPE(Name, Id, SingletonId) CanQualType SingletonId;
+#define AMDGPU_TYPE(Name, Id, SingletonId, Width, Align)   
\
+  CanQualType SingletonId;
 #include "clang/Basic/AMDGPUTypes.def"
 #define HLSL_INTANGIBLE_TYPE(Name, Id, SingletonId) CanQualType SingletonId;
 #include "clang/Basic/HLSLIntangibleTypes.def"
diff --git a/clang/include/clang/AST/Type.h b/clang/include/clang/AST/Type.h
index dc87b84153e74a..cee4e68fe0dc6d 100644
--- a/clang/include/clang/AST/Type.h
+++ b/clang/include/clang/AST/Type.h
@@ -3050,7 +3050,7 @@ class BuiltinType : public Type {
 #define WASM_TYPE(Name, Id, SingletonId) Id,
 #include "clang/Basic/WebAssemblyReferenceTypes.def"
 // AMDGPU types
-#define AMDGPU_TYPE(Name, Id, SingletonId) Id,
+#define AMDGPU_TYPE(Name, Id, SingletonId, Width, Align) Id,
 #include "clang/Basic/AMDGPUTypes.def"
 // HLSL intangible Types
 #define HLSL_INTANGIBLE_TYPE(Name, Id, SingletonId) Id,
diff --git a/clang/include/clang/AST/TypeProperties.td 
b/clang/include/clang/AST/TypeProperties.td
index bb7bfa8cd0b76e..d05072607e949c 100644
--- a/clang/include/clang/AST/TypeProperties.td
+++ b/clang/include/clang/AST/TypeProperties.td
@@ -893,7 +893,7 @@ let Class = BuiltinType in {
   case BuiltinType::ID: return ctx.SINGLETON_ID;
 #include "clang/Basic/WebAssemblyReferenceTypes.def"
 
-#define AMDGPU_TYPE(NAME, ID, SINGLETON_ID) \
+#define AMDGPU_TYPE(NAME, ID, SINGLETON_ID, WIDTH, ALIGN) \
   case BuiltinType::ID: return ctx.SINGLETON_ID;
 #include "clang/Basic/AMDGPUTypes.def"
 
diff --git a/clang/include/clang/Basic/AMDGPUTypes.def 
b/clang/include/clang/Basic/AMDGPUTypes.def
index 7454d61f5dd516..e47e544fdc82c1 100644
--- a/clang/include/clang/Basic/AMDGPUTypes.def
+++ b/clang/include/clang/Basic/AMDGPUTypes.def
@@ -11,11 +11,11 @@
 
//===--===//
 
 #ifndef AMDGPU_OPAQUE_PTR_TYPE
-#define AMDGPU_OPAQUE_PTR_TYPE(Name, AS, Width, Align, Id, SingletonId) \
-  AMDGPU_TYPE(Name, Id, SingletonId)
+#define AMDGPU_OPAQUE_PTR_TYPE(Name, Id, SingletonId, Width, Align, AS) \
+  AMDGPU_TYPE(Name, Id, SingletonId, Width, Align)
 #endif
 
-AMDGPU_OPAQUE_PTR_TYPE("__amdgpu_buffer_rsrc_t", 8, 128, 128, 
AMDGPUBufferRsrc, AMDGPUBufferRsrcTy)
+AMDGPU_OPAQUE_PTR_TYPE("__amdgpu_buffer

[Lldb-commits] [clang] [lldb] [AMDGPU] Specify width and align for all AMDGPU builtin types. NFC. (PR #109656)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Jay Foad (jayfoad)


Changes

This will be used in ASTContext::getTypeInfo which needs this
information for all builtin types, not just pointers.


---

Patch is 20.84 KiB, truncated to 20.00 KiB below, full version: 
https://github.com/llvm/llvm-project/pull/109656.diff


25 Files Affected:

- (modified) clang/include/clang/AST/ASTContext.h (+2-1) 
- (modified) clang/include/clang/AST/Type.h (+1-1) 
- (modified) clang/include/clang/AST/TypeProperties.td (+1-1) 
- (modified) clang/include/clang/Basic/AMDGPUTypes.def (+3-3) 
- (modified) clang/include/clang/Serialization/ASTBitCodes.h (+1-1) 
- (modified) clang/lib/AST/ASTContext.cpp (+4-4) 
- (modified) clang/lib/AST/ASTImporter.cpp (+1-1) 
- (modified) clang/lib/AST/ExprConstant.cpp (+1-1) 
- (modified) clang/lib/AST/ItaniumMangle.cpp (+1-1) 
- (modified) clang/lib/AST/MicrosoftMangle.cpp (+1-1) 
- (modified) clang/lib/AST/NSAPI.cpp (+1-1) 
- (modified) clang/lib/AST/PrintfFormatString.cpp (+1-1) 
- (modified) clang/lib/AST/Type.cpp (+2-2) 
- (modified) clang/lib/AST/TypeLoc.cpp (+1-1) 
- (modified) clang/lib/CodeGen/CGDebugInfo.cpp (+1-1) 
- (modified) clang/lib/CodeGen/CGDebugInfo.h (+2-1) 
- (modified) clang/lib/CodeGen/CodeGenTypes.cpp (+1-1) 
- (modified) clang/lib/CodeGen/ItaniumCXXABI.cpp (+1-1) 
- (modified) clang/lib/Index/USRGeneration.cpp (+1-1) 
- (modified) clang/lib/Sema/Sema.cpp (+1-1) 
- (modified) clang/lib/Sema/SemaExpr.cpp (+2-2) 
- (modified) clang/lib/Serialization/ASTCommon.cpp (+1-1) 
- (modified) clang/lib/Serialization/ASTReader.cpp (+1-1) 
- (modified) clang/tools/libclang/CIndex.cpp (+1-1) 
- (modified) lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp (+2-1) 


``diff
diff --git a/clang/include/clang/AST/ASTContext.h 
b/clang/include/clang/AST/ASTContext.h
index 1984310df0442e..f46e12a57d4c38 100644
--- a/clang/include/clang/AST/ASTContext.h
+++ b/clang/include/clang/AST/ASTContext.h
@@ -1197,7 +1197,8 @@ class ASTContext : public RefCountedBase {
 #include "clang/Basic/RISCVVTypes.def"
 #define WASM_TYPE(Name, Id, SingletonId) CanQualType SingletonId;
 #include "clang/Basic/WebAssemblyReferenceTypes.def"
-#define AMDGPU_TYPE(Name, Id, SingletonId) CanQualType SingletonId;
+#define AMDGPU_TYPE(Name, Id, SingletonId, Width, Align)   
\
+  CanQualType SingletonId;
 #include "clang/Basic/AMDGPUTypes.def"
 #define HLSL_INTANGIBLE_TYPE(Name, Id, SingletonId) CanQualType SingletonId;
 #include "clang/Basic/HLSLIntangibleTypes.def"
diff --git a/clang/include/clang/AST/Type.h b/clang/include/clang/AST/Type.h
index dc87b84153e74a..cee4e68fe0dc6d 100644
--- a/clang/include/clang/AST/Type.h
+++ b/clang/include/clang/AST/Type.h
@@ -3050,7 +3050,7 @@ class BuiltinType : public Type {
 #define WASM_TYPE(Name, Id, SingletonId) Id,
 #include "clang/Basic/WebAssemblyReferenceTypes.def"
 // AMDGPU types
-#define AMDGPU_TYPE(Name, Id, SingletonId) Id,
+#define AMDGPU_TYPE(Name, Id, SingletonId, Width, Align) Id,
 #include "clang/Basic/AMDGPUTypes.def"
 // HLSL intangible Types
 #define HLSL_INTANGIBLE_TYPE(Name, Id, SingletonId) Id,
diff --git a/clang/include/clang/AST/TypeProperties.td 
b/clang/include/clang/AST/TypeProperties.td
index bb7bfa8cd0b76e..d05072607e949c 100644
--- a/clang/include/clang/AST/TypeProperties.td
+++ b/clang/include/clang/AST/TypeProperties.td
@@ -893,7 +893,7 @@ let Class = BuiltinType in {
   case BuiltinType::ID: return ctx.SINGLETON_ID;
 #include "clang/Basic/WebAssemblyReferenceTypes.def"
 
-#define AMDGPU_TYPE(NAME, ID, SINGLETON_ID) \
+#define AMDGPU_TYPE(NAME, ID, SINGLETON_ID, WIDTH, ALIGN) \
   case BuiltinType::ID: return ctx.SINGLETON_ID;
 #include "clang/Basic/AMDGPUTypes.def"
 
diff --git a/clang/include/clang/Basic/AMDGPUTypes.def 
b/clang/include/clang/Basic/AMDGPUTypes.def
index 7454d61f5dd516..e47e544fdc82c1 100644
--- a/clang/include/clang/Basic/AMDGPUTypes.def
+++ b/clang/include/clang/Basic/AMDGPUTypes.def
@@ -11,11 +11,11 @@
 
//===--===//
 
 #ifndef AMDGPU_OPAQUE_PTR_TYPE
-#define AMDGPU_OPAQUE_PTR_TYPE(Name, AS, Width, Align, Id, SingletonId) \
-  AMDGPU_TYPE(Name, Id, SingletonId)
+#define AMDGPU_OPAQUE_PTR_TYPE(Name, Id, SingletonId, Width, Align, AS) \
+  AMDGPU_TYPE(Name, Id, SingletonId, Width, Align)
 #endif
 
-AMDGPU_OPAQUE_PTR_TYPE("__amdgpu_buffer_rsrc_t", 8, 128, 128, 
AMDGPUBufferRsrc, AMDGPUBufferRsrcTy)
+AMDGPU_OPAQUE_PTR_TYPE("__amdgpu_buffer_rsrc_t", AMDGPUBufferRsrc, 
AMDGPUBufferRsrcTy, 128, 128, 8)
 
 #undef AMDGPU_TYPE
 #undef AMDGPU_OPAQUE_PTR_TYPE
diff --git a/clang/include/clang/Serialization/ASTBitCodes.h 
b/clang/include/clang/Serialization/ASTBitCodes.h
index 4410df296d8efc..8c29f8c0ae5f55 100644
--- a/clang/include/clang/Serialization/ASTBitCodes.h
+++ b/clang/include/clang/Serialization/ASTBitCodes.h
@@ -1122,7 +1122,7 @@ enum PredefinedTypeIDs {
 #define WASM_TYPE(Name, Id, SingletonId) PREDEF_TYPE_##Id##_I

[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

[Pavel Labath via lldb-commits]

@@ -393,125 +362,222 @@ int main_platform(int argc, char *argv[]) {
   lldb_private::Args inferior_arguments;
   inferior_arguments.SetArguments(argc, const_cast(argv));
 
+  Socket::SocketProtocol protocol = Socket::ProtocolUnixDomain;
+
   if (fd != SharedSocket::kInvalidFD) {
 // Child process will handle the connection and exit.
+if (gdbserver_port)
+  protocol = Socket::ProtocolTcp;
+
 Log *log = GetLog(LLDBLog::Platform);
-if (!listen_host_port.empty()) {
-  LLDB_LOGF(log, "lldb-platform child: "
- "ambiguous parameters --listen and --child-platform-fd");
-  return socket_error;
-}
 
-NativeSocket socket;
-error = SharedSocket::GetNativeSocket(fd, socket);
+NativeSocket sockfd;
+error = SharedSocket::GetNativeSocket(fd, sockfd);
 if (error.Fail()) {
   LLDB_LOGF(log, "lldb-platform child: %s", error.AsCString());
   return socket_error;
 }
 
-GDBRemoteCommunicationServerPlatform platform(Socket::ProtocolTcp, "tcp");
-if (port_offset > 0)
-  platform.SetPortOffset(port_offset);
-platform.SetPortMap(std::move(gdbserver_portmap));
+GDBRemoteCommunicationServerPlatform platform(protocol, gdbserver_port);
+Socket *socket;
+if (protocol == Socket::ProtocolTcp)
+  socket = new TCPSocket(sockfd, /*should_close=*/true,
+ /*child_processes_inherit=*/false);
+else {
+#if LLDB_ENABLE_POSIX
+  socket = new DomainSocket(sockfd, /*should_close=*/true,
+/*child_processes_inherit=*/false);
+#else
+  LLDB_LOGF(log,
+"lldb-platform child: Unix domain sockets are not supported on 
"
+"this platform.");
+  return socket_error;
+#endif
+}
 platform.SetConnection(
-std::unique_ptr(new ConnectionFileDescriptor(
-new TCPSocket(socket, /*should_close=*/true,
-  /*child_processes_inherit=*/false;
+std::unique_ptr(new ConnectionFileDescriptor(socket)));
 client_handle(platform, inferior_arguments);
 return 0;
   }
 
-  const bool children_inherit_listen_socket = false;
-  // the test suite makes many connections in parallel, let's not miss any.
-  // The highest this should get reasonably is a function of the number
-  // of target CPUs. For now, let's just use 100.
-  const int backlog = 100;
+  if (gdbserver_port != 0 &&
+  (gdbserver_port < LOW_PORT || gdbserver_port > HIGH_PORT)) {
+WithColor::error() << llvm::formatv("Port number {0} is not in the "
+"valid user port range of {1} - {2}\n",
+gdbserver_port, LOW_PORT, HIGH_PORT);
+return 1;
+  }
 
-  std::unique_ptr acceptor_up(Acceptor::Create(
-  listen_host_port, children_inherit_listen_socket, error));
-  if (error.Fail()) {
-fprintf(stderr, "failed to create acceptor: %s", error.AsCString());
-exit(socket_error);
+  std::string hostname;
+  uint16_t platform_port = 0;
+
+  // Try to match socket name as URL - e.g., tcp://localhost:
+  if (std::optional uri = URI::Parse(listen_host_port)) {
+if (!Socket::FindProtocolByScheme(uri->scheme.str().c_str(), protocol)) {
+  fprintf(stderr, "Unknown protocol scheme \"%s\".",
+  uri->scheme.str().c_str());
+  return socket_error;
+}
+if (protocol == Socket::ProtocolTcp) {
+  hostname = uri->hostname;
+  if (uri->port) {
+platform_port = *(uri->port);
+  }
+} else
+  hostname = listen_host_port.substr(uri->scheme.size() + strlen("://"));
+  } else {
+// Try to match socket name as $host:port - e.g., localhost:
+llvm::Expected host_port =
+Socket::DecodeHostAndPort(listen_host_port);
+if (!llvm::errorToBool(host_port.takeError())) {
+  protocol = Socket::ProtocolTcp;
+  hostname = host_port->hostname;
+  platform_port = host_port->port;
+} else
+  hostname = listen_host_port;
   }
 
-  error = acceptor_up->Listen(backlog);
+  if (protocol == Socket::ProtocolTcp) {
+if (platform_port != 0 && platform_port == gdbserver_port) {
+  fprintf(stderr, "The same platform and gdb ports %u.", platform_port);
+  return socket_error;
+}
+  } else {
+if (gdbserver_port) {
+  fprintf(stderr,
+  "--gdbserver-port %u is redundant for non-tcp protocol %s.",
+  gdbserver_port, Socket::FindSchemeByProtocol(protocol));
+  return socket_error;
+}
+if (g_server) {
+  fprintf(stderr,
+  "Ambiguous parameters --server --listen %s.\n"
+  "The protocol must be tcp for the server mode.",
+  listen_host_port.c_str());
+  return socket_error;

labath wrote:

Why is that the case? I'd like the combination to work (it does right now).

https://github.com/llvm/llvm-project/pull/104238
__

[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

[Pavel Labath via lldb-commits]

@@ -393,125 +362,222 @@ int main_platform(int argc, char *argv[]) {
   lldb_private::Args inferior_arguments;
   inferior_arguments.SetArguments(argc, const_cast(argv));
 
+  Socket::SocketProtocol protocol = Socket::ProtocolUnixDomain;
+
   if (fd != SharedSocket::kInvalidFD) {
 // Child process will handle the connection and exit.
+if (gdbserver_port)
+  protocol = Socket::ProtocolTcp;
+
 Log *log = GetLog(LLDBLog::Platform);
-if (!listen_host_port.empty()) {
-  LLDB_LOGF(log, "lldb-platform child: "
- "ambiguous parameters --listen and --child-platform-fd");
-  return socket_error;
-}
 
-NativeSocket socket;
-error = SharedSocket::GetNativeSocket(fd, socket);
+NativeSocket sockfd;
+error = SharedSocket::GetNativeSocket(fd, sockfd);
 if (error.Fail()) {
   LLDB_LOGF(log, "lldb-platform child: %s", error.AsCString());
   return socket_error;
 }
 
-GDBRemoteCommunicationServerPlatform platform(Socket::ProtocolTcp, "tcp");
-if (port_offset > 0)
-  platform.SetPortOffset(port_offset);
-platform.SetPortMap(std::move(gdbserver_portmap));
+GDBRemoteCommunicationServerPlatform platform(protocol, gdbserver_port);
+Socket *socket;
+if (protocol == Socket::ProtocolTcp)
+  socket = new TCPSocket(sockfd, /*should_close=*/true,
+ /*child_processes_inherit=*/false);
+else {
+#if LLDB_ENABLE_POSIX
+  socket = new DomainSocket(sockfd, /*should_close=*/true,
+/*child_processes_inherit=*/false);
+#else
+  LLDB_LOGF(log,
+"lldb-platform child: Unix domain sockets are not supported on 
"
+"this platform.");
+  return socket_error;
+#endif
+}
 platform.SetConnection(
-std::unique_ptr(new ConnectionFileDescriptor(
-new TCPSocket(socket, /*should_close=*/true,
-  /*child_processes_inherit=*/false;
+std::unique_ptr(new ConnectionFileDescriptor(socket)));
 client_handle(platform, inferior_arguments);
 return 0;
   }
 
-  const bool children_inherit_listen_socket = false;
-  // the test suite makes many connections in parallel, let's not miss any.
-  // The highest this should get reasonably is a function of the number
-  // of target CPUs. For now, let's just use 100.
-  const int backlog = 100;
+  if (gdbserver_port != 0 &&
+  (gdbserver_port < LOW_PORT || gdbserver_port > HIGH_PORT)) {
+WithColor::error() << llvm::formatv("Port number {0} is not in the "
+"valid user port range of {1} - {2}\n",
+gdbserver_port, LOW_PORT, HIGH_PORT);
+return 1;
+  }
 
-  std::unique_ptr acceptor_up(Acceptor::Create(
-  listen_host_port, children_inherit_listen_socket, error));
-  if (error.Fail()) {
-fprintf(stderr, "failed to create acceptor: %s", error.AsCString());
-exit(socket_error);
+  std::string hostname;
+  uint16_t platform_port = 0;
+
+  // Try to match socket name as URL - e.g., tcp://localhost:
+  if (std::optional uri = URI::Parse(listen_host_port)) {
+if (!Socket::FindProtocolByScheme(uri->scheme.str().c_str(), protocol)) {
+  fprintf(stderr, "Unknown protocol scheme \"%s\".",
+  uri->scheme.str().c_str());
+  return socket_error;
+}
+if (protocol == Socket::ProtocolTcp) {
+  hostname = uri->hostname;
+  if (uri->port) {
+platform_port = *(uri->port);
+  }
+} else
+  hostname = listen_host_port.substr(uri->scheme.size() + strlen("://"));
+  } else {
+// Try to match socket name as $host:port - e.g., localhost:
+llvm::Expected host_port =
+Socket::DecodeHostAndPort(listen_host_port);
+if (!llvm::errorToBool(host_port.takeError())) {
+  protocol = Socket::ProtocolTcp;
+  hostname = host_port->hostname;
+  platform_port = host_port->port;
+} else
+  hostname = listen_host_port;
   }
 
-  error = acceptor_up->Listen(backlog);
+  if (protocol == Socket::ProtocolTcp) {
+if (platform_port != 0 && platform_port == gdbserver_port) {
+  fprintf(stderr, "The same platform and gdb ports %u.", platform_port);
+  return socket_error;
+}
+  } else {
+if (gdbserver_port) {
+  fprintf(stderr,
+  "--gdbserver-port %u is redundant for non-tcp protocol %s.",
+  gdbserver_port, Socket::FindSchemeByProtocol(protocol));
+  return socket_error;
+}
+if (g_server) {
+  fprintf(stderr,
+  "Ambiguous parameters --server --listen %s.\n"
+  "The protocol must be tcp for the server mode.",
+  listen_host_port.c_str());
+  return socket_error;
+}
+  }
+
+  std::unique_ptr sock_platform =
+  Socket::Create(protocol, /*child_processes_inherit=*/false, error);
+  if (error.Fail()) {
+printf("Failed to create platform socket: %s\n", err

[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

[Pavel Labath via lldb-commits]

@@ -393,125 +362,222 @@ int main_platform(int argc, char *argv[]) {
   lldb_private::Args inferior_arguments;
   inferior_arguments.SetArguments(argc, const_cast(argv));
 
+  Socket::SocketProtocol protocol = Socket::ProtocolUnixDomain;
+
   if (fd != SharedSocket::kInvalidFD) {
 // Child process will handle the connection and exit.
+if (gdbserver_port)
+  protocol = Socket::ProtocolTcp;
+
 Log *log = GetLog(LLDBLog::Platform);
-if (!listen_host_port.empty()) {
-  LLDB_LOGF(log, "lldb-platform child: "
- "ambiguous parameters --listen and --child-platform-fd");
-  return socket_error;
-}
 
-NativeSocket socket;
-error = SharedSocket::GetNativeSocket(fd, socket);
+NativeSocket sockfd;
+error = SharedSocket::GetNativeSocket(fd, sockfd);
 if (error.Fail()) {
   LLDB_LOGF(log, "lldb-platform child: %s", error.AsCString());
   return socket_error;
 }
 
-GDBRemoteCommunicationServerPlatform platform(Socket::ProtocolTcp, "tcp");
-if (port_offset > 0)
-  platform.SetPortOffset(port_offset);
-platform.SetPortMap(std::move(gdbserver_portmap));
+GDBRemoteCommunicationServerPlatform platform(protocol, gdbserver_port);
+Socket *socket;
+if (protocol == Socket::ProtocolTcp)
+  socket = new TCPSocket(sockfd, /*should_close=*/true,
+ /*child_processes_inherit=*/false);
+else {
+#if LLDB_ENABLE_POSIX
+  socket = new DomainSocket(sockfd, /*should_close=*/true,
+/*child_processes_inherit=*/false);
+#else
+  LLDB_LOGF(log,
+"lldb-platform child: Unix domain sockets are not supported on 
"
+"this platform.");
+  return socket_error;
+#endif
+}
 platform.SetConnection(
-std::unique_ptr(new ConnectionFileDescriptor(
-new TCPSocket(socket, /*should_close=*/true,
-  /*child_processes_inherit=*/false;
+std::unique_ptr(new ConnectionFileDescriptor(socket)));
 client_handle(platform, inferior_arguments);
 return 0;
   }
 
-  const bool children_inherit_listen_socket = false;
-  // the test suite makes many connections in parallel, let's not miss any.
-  // The highest this should get reasonably is a function of the number
-  // of target CPUs. For now, let's just use 100.
-  const int backlog = 100;
+  if (gdbserver_port != 0 &&
+  (gdbserver_port < LOW_PORT || gdbserver_port > HIGH_PORT)) {
+WithColor::error() << llvm::formatv("Port number {0} is not in the "
+"valid user port range of {1} - {2}\n",
+gdbserver_port, LOW_PORT, HIGH_PORT);
+return 1;
+  }
 
-  std::unique_ptr acceptor_up(Acceptor::Create(
-  listen_host_port, children_inherit_listen_socket, error));
-  if (error.Fail()) {
-fprintf(stderr, "failed to create acceptor: %s", error.AsCString());
-exit(socket_error);
+  std::string hostname;
+  uint16_t platform_port = 0;
+
+  // Try to match socket name as URL - e.g., tcp://localhost:
+  if (std::optional uri = URI::Parse(listen_host_port)) {
+if (!Socket::FindProtocolByScheme(uri->scheme.str().c_str(), protocol)) {
+  fprintf(stderr, "Unknown protocol scheme \"%s\".",
+  uri->scheme.str().c_str());
+  return socket_error;
+}
+if (protocol == Socket::ProtocolTcp) {
+  hostname = uri->hostname;
+  if (uri->port) {
+platform_port = *(uri->port);
+  }
+} else
+  hostname = listen_host_port.substr(uri->scheme.size() + strlen("://"));
+  } else {
+// Try to match socket name as $host:port - e.g., localhost:
+llvm::Expected host_port =
+Socket::DecodeHostAndPort(listen_host_port);
+if (!llvm::errorToBool(host_port.takeError())) {
+  protocol = Socket::ProtocolTcp;
+  hostname = host_port->hostname;
+  platform_port = host_port->port;
+} else
+  hostname = listen_host_port;
   }
 
-  error = acceptor_up->Listen(backlog);
+  if (protocol == Socket::ProtocolTcp) {
+if (platform_port != 0 && platform_port == gdbserver_port) {
+  fprintf(stderr, "The same platform and gdb ports %u.", platform_port);
+  return socket_error;
+}
+  } else {
+if (gdbserver_port) {
+  fprintf(stderr,
+  "--gdbserver-port %u is redundant for non-tcp protocol %s.",
+  gdbserver_port, Socket::FindSchemeByProtocol(protocol));
+  return socket_error;
+}
+if (g_server) {
+  fprintf(stderr,
+  "Ambiguous parameters --server --listen %s.\n"
+  "The protocol must be tcp for the server mode.",
+  listen_host_port.c_str());
+  return socket_error;
+}
+  }
+
+  std::unique_ptr sock_platform =
+  Socket::Create(protocol, /*child_processes_inherit=*/false, error);
+  if (error.Fail()) {
+printf("Failed to create platform socket: %s\n", err

[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

[Pavel Labath via lldb-commits]

@@ -195,18 +195,31 @@ void ConnectToRemote(MainLoop &mainloop,
  bool reverse_connect, llvm::StringRef host_and_port,
  const char *const progname, const char *const subcommand,
  const char *const named_pipe_path, pipe_t unnamed_pipe,
- int connection_fd) {
+ shared_fd_t connection_fd) {
   Status error;
 
   std::unique_ptr connection_up;
   std::string url;
 
-  if (connection_fd != -1) {
+  if (connection_fd != SharedSocket::kInvalidFD) {
+#ifdef _WIN32
+NativeSocket sockfd;
+error = SharedSocket::GetNativeSocket(connection_fd, sockfd);
+if (error.Fail()) {
+  llvm::errs() << llvm::formatv("error: GetNativeSocket failed: {0}\n",
+error.AsCString());
+  exit(-1);
+}
+connection_up =
+std::unique_ptr(new ConnectionFileDescriptor(new TCPSocket(
+sockfd, /*should_close=*/true, 
/*child_processes_inherit=*/false)));
+#else
 url = llvm::formatv("fd://{0}", connection_fd).str();
 
 // Create the connection.
-#if LLDB_ENABLE_POSIX && !defined _WIN32
+#if LLDB_ENABLE_POSIX

labath wrote:

I'm not saying we should add `_WIN32`. I'm saying we should *remove* the POSIX 
check, as `_WIN32 == !POSIX` (right now, and for the foreseeable future).

https://github.com/llvm/llvm-project/pull/104238
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

[Pavel Labath via lldb-commits]

@@ -393,125 +362,222 @@ int main_platform(int argc, char *argv[]) {
   lldb_private::Args inferior_arguments;
   inferior_arguments.SetArguments(argc, const_cast(argv));
 
+  Socket::SocketProtocol protocol = Socket::ProtocolUnixDomain;
+
   if (fd != SharedSocket::kInvalidFD) {
 // Child process will handle the connection and exit.
+if (gdbserver_port)
+  protocol = Socket::ProtocolTcp;
+
 Log *log = GetLog(LLDBLog::Platform);
-if (!listen_host_port.empty()) {
-  LLDB_LOGF(log, "lldb-platform child: "
- "ambiguous parameters --listen and --child-platform-fd");
-  return socket_error;
-}
 
-NativeSocket socket;
-error = SharedSocket::GetNativeSocket(fd, socket);
+NativeSocket sockfd;
+error = SharedSocket::GetNativeSocket(fd, sockfd);
 if (error.Fail()) {
   LLDB_LOGF(log, "lldb-platform child: %s", error.AsCString());
   return socket_error;
 }
 
-GDBRemoteCommunicationServerPlatform platform(Socket::ProtocolTcp, "tcp");
-if (port_offset > 0)
-  platform.SetPortOffset(port_offset);
-platform.SetPortMap(std::move(gdbserver_portmap));
+GDBRemoteCommunicationServerPlatform platform(protocol, gdbserver_port);
+Socket *socket;
+if (protocol == Socket::ProtocolTcp)
+  socket = new TCPSocket(sockfd, /*should_close=*/true,
+ /*child_processes_inherit=*/false);
+else {
+#if LLDB_ENABLE_POSIX
+  socket = new DomainSocket(sockfd, /*should_close=*/true,
+/*child_processes_inherit=*/false);
+#else
+  LLDB_LOGF(log,
+"lldb-platform child: Unix domain sockets are not supported on 
"
+"this platform.");
+  return socket_error;
+#endif
+}
 platform.SetConnection(
-std::unique_ptr(new ConnectionFileDescriptor(
-new TCPSocket(socket, /*should_close=*/true,
-  /*child_processes_inherit=*/false;
+std::unique_ptr(new ConnectionFileDescriptor(socket)));
 client_handle(platform, inferior_arguments);
 return 0;
   }
 
-  const bool children_inherit_listen_socket = false;
-  // the test suite makes many connections in parallel, let's not miss any.
-  // The highest this should get reasonably is a function of the number
-  // of target CPUs. For now, let's just use 100.
-  const int backlog = 100;
+  if (gdbserver_port != 0 &&
+  (gdbserver_port < LOW_PORT || gdbserver_port > HIGH_PORT)) {
+WithColor::error() << llvm::formatv("Port number {0} is not in the "
+"valid user port range of {1} - {2}\n",
+gdbserver_port, LOW_PORT, HIGH_PORT);
+return 1;
+  }
 
-  std::unique_ptr acceptor_up(Acceptor::Create(
-  listen_host_port, children_inherit_listen_socket, error));
-  if (error.Fail()) {
-fprintf(stderr, "failed to create acceptor: %s", error.AsCString());
-exit(socket_error);
+  std::string hostname;
+  uint16_t platform_port = 0;
+
+  // Try to match socket name as URL - e.g., tcp://localhost:
+  if (std::optional uri = URI::Parse(listen_host_port)) {
+if (!Socket::FindProtocolByScheme(uri->scheme.str().c_str(), protocol)) {
+  fprintf(stderr, "Unknown protocol scheme \"%s\".",
+  uri->scheme.str().c_str());
+  return socket_error;
+}
+if (protocol == Socket::ProtocolTcp) {
+  hostname = uri->hostname;
+  if (uri->port) {
+platform_port = *(uri->port);
+  }
+} else
+  hostname = listen_host_port.substr(uri->scheme.size() + strlen("://"));
+  } else {
+// Try to match socket name as $host:port - e.g., localhost:
+llvm::Expected host_port =
+Socket::DecodeHostAndPort(listen_host_port);
+if (!llvm::errorToBool(host_port.takeError())) {
+  protocol = Socket::ProtocolTcp;
+  hostname = host_port->hostname;
+  platform_port = host_port->port;
+} else
+  hostname = listen_host_port;
   }
 
-  error = acceptor_up->Listen(backlog);
+  if (protocol == Socket::ProtocolTcp) {
+if (platform_port != 0 && platform_port == gdbserver_port) {
+  fprintf(stderr, "The same platform and gdb ports %u.", platform_port);
+  return socket_error;
+}
+  } else {
+if (gdbserver_port) {
+  fprintf(stderr,
+  "--gdbserver-port %u is redundant for non-tcp protocol %s.",
+  gdbserver_port, Socket::FindSchemeByProtocol(protocol));
+  return socket_error;
+}
+if (g_server) {
+  fprintf(stderr,
+  "Ambiguous parameters --server --listen %s.\n"
+  "The protocol must be tcp for the server mode.",
+  listen_host_port.c_str());
+  return socket_error;
+}
+  }
+
+  std::unique_ptr sock_platform =
+  Socket::Create(protocol, /*child_processes_inherit=*/false, error);
+  if (error.Fail()) {
+printf("Failed to create platform socket: %s\n", err

[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

[Pavel Labath via lldb-commits]

@@ -160,66 +95,56 @@ 
GDBRemoteCommunicationServerPlatform::~GDBRemoteCommunicationServerPlatform() =
 default;
 
 Status GDBRemoteCommunicationServerPlatform::LaunchGDBServer(
-const lldb_private::Args &args, std::string hostname, lldb::pid_t &pid,
-std::optional &port, std::string &socket_name) {
-  if (!port) {
-llvm::Expected available_port = 
m_port_map.GetNextAvailablePort();
-if (available_port)
-  port = *available_port;
-else
-  return Status(available_port.takeError());
-  }
-
-  // Spawn a new thread to accept the port that gets bound after binding to
-  // port 0 (zero).
+const lldb_private::Args &args, lldb::pid_t &pid, std::string &socket_name,
+shared_fd_t fd) {
+  std::ostringstream url;
+  if (fd == SharedSocket::kInvalidFD) {
+if (m_socket_protocol == Socket::ProtocolTcp) {
+  // Just check that GDBServer exists. GDBServer must be launched after
+  // accepting the connection.
+  if (!GetDebugserverPath(nullptr))
+return Status::FromErrorString("unable to locate debugserver");
+  return Status();

labath wrote:

But do both of those callers need the "optional launch" functionality? AIUI, 
it's only the Handle_qLaunchGDBServer that does, and the code in 
lldb-platform.cpp should launch a server unconditionally.

https://github.com/llvm/llvm-project/pull/104238
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

[Pavel Labath via lldb-commits]

@@ -393,125 +362,222 @@ int main_platform(int argc, char *argv[]) {
   lldb_private::Args inferior_arguments;
   inferior_arguments.SetArguments(argc, const_cast(argv));
 
+  Socket::SocketProtocol protocol = Socket::ProtocolUnixDomain;
+
   if (fd != SharedSocket::kInvalidFD) {
 // Child process will handle the connection and exit.
+if (gdbserver_port)
+  protocol = Socket::ProtocolTcp;
+
 Log *log = GetLog(LLDBLog::Platform);
-if (!listen_host_port.empty()) {
-  LLDB_LOGF(log, "lldb-platform child: "
- "ambiguous parameters --listen and --child-platform-fd");
-  return socket_error;
-}
 
-NativeSocket socket;
-error = SharedSocket::GetNativeSocket(fd, socket);
+NativeSocket sockfd;
+error = SharedSocket::GetNativeSocket(fd, sockfd);
 if (error.Fail()) {
   LLDB_LOGF(log, "lldb-platform child: %s", error.AsCString());
   return socket_error;
 }
 
-GDBRemoteCommunicationServerPlatform platform(Socket::ProtocolTcp, "tcp");
-if (port_offset > 0)
-  platform.SetPortOffset(port_offset);
-platform.SetPortMap(std::move(gdbserver_portmap));
+GDBRemoteCommunicationServerPlatform platform(protocol, gdbserver_port);
+Socket *socket;
+if (protocol == Socket::ProtocolTcp)
+  socket = new TCPSocket(sockfd, /*should_close=*/true,
+ /*child_processes_inherit=*/false);
+else {
+#if LLDB_ENABLE_POSIX
+  socket = new DomainSocket(sockfd, /*should_close=*/true,
+/*child_processes_inherit=*/false);
+#else
+  LLDB_LOGF(log,
+"lldb-platform child: Unix domain sockets are not supported on 
"
+"this platform.");
+  return socket_error;
+#endif
+}
 platform.SetConnection(
-std::unique_ptr(new ConnectionFileDescriptor(
-new TCPSocket(socket, /*should_close=*/true,
-  /*child_processes_inherit=*/false;
+std::unique_ptr(new ConnectionFileDescriptor(socket)));
 client_handle(platform, inferior_arguments);
 return 0;
   }
 
-  const bool children_inherit_listen_socket = false;
-  // the test suite makes many connections in parallel, let's not miss any.
-  // The highest this should get reasonably is a function of the number
-  // of target CPUs. For now, let's just use 100.
-  const int backlog = 100;
+  if (gdbserver_port != 0 &&
+  (gdbserver_port < LOW_PORT || gdbserver_port > HIGH_PORT)) {
+WithColor::error() << llvm::formatv("Port number {0} is not in the "
+"valid user port range of {1} - {2}\n",
+gdbserver_port, LOW_PORT, HIGH_PORT);
+return 1;
+  }
 
-  std::unique_ptr acceptor_up(Acceptor::Create(
-  listen_host_port, children_inherit_listen_socket, error));
-  if (error.Fail()) {
-fprintf(stderr, "failed to create acceptor: %s", error.AsCString());
-exit(socket_error);
+  std::string hostname;
+  uint16_t platform_port = 0;
+
+  // Try to match socket name as URL - e.g., tcp://localhost:
+  if (std::optional uri = URI::Parse(listen_host_port)) {
+if (!Socket::FindProtocolByScheme(uri->scheme.str().c_str(), protocol)) {
+  fprintf(stderr, "Unknown protocol scheme \"%s\".",
+  uri->scheme.str().c_str());
+  return socket_error;
+}
+if (protocol == Socket::ProtocolTcp) {
+  hostname = uri->hostname;
+  if (uri->port) {
+platform_port = *(uri->port);
+  }
+} else
+  hostname = listen_host_port.substr(uri->scheme.size() + strlen("://"));
+  } else {
+// Try to match socket name as $host:port - e.g., localhost:
+llvm::Expected host_port =
+Socket::DecodeHostAndPort(listen_host_port);
+if (!llvm::errorToBool(host_port.takeError())) {
+  protocol = Socket::ProtocolTcp;
+  hostname = host_port->hostname;
+  platform_port = host_port->port;
+} else
+  hostname = listen_host_port;
   }

labath wrote:

Let's make a helper function for this. It could either return a 
decomposed/parsed socket address or maybe even a constructed socket object.

https://github.com/llvm/llvm-project/pull/104238
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

[Pavel Labath via lldb-commits]

@@ -393,125 +362,222 @@ int main_platform(int argc, char *argv[]) {
   lldb_private::Args inferior_arguments;
   inferior_arguments.SetArguments(argc, const_cast(argv));
 
+  Socket::SocketProtocol protocol = Socket::ProtocolUnixDomain;
+
   if (fd != SharedSocket::kInvalidFD) {
 // Child process will handle the connection and exit.
+if (gdbserver_port)
+  protocol = Socket::ProtocolTcp;
+
 Log *log = GetLog(LLDBLog::Platform);
-if (!listen_host_port.empty()) {
-  LLDB_LOGF(log, "lldb-platform child: "
- "ambiguous parameters --listen and --child-platform-fd");
-  return socket_error;
-}
 
-NativeSocket socket;
-error = SharedSocket::GetNativeSocket(fd, socket);
+NativeSocket sockfd;
+error = SharedSocket::GetNativeSocket(fd, sockfd);
 if (error.Fail()) {
   LLDB_LOGF(log, "lldb-platform child: %s", error.AsCString());
   return socket_error;
 }
 
-GDBRemoteCommunicationServerPlatform platform(Socket::ProtocolTcp, "tcp");
-if (port_offset > 0)
-  platform.SetPortOffset(port_offset);
-platform.SetPortMap(std::move(gdbserver_portmap));
+GDBRemoteCommunicationServerPlatform platform(protocol, gdbserver_port);
+Socket *socket;
+if (protocol == Socket::ProtocolTcp)
+  socket = new TCPSocket(sockfd, /*should_close=*/true,
+ /*child_processes_inherit=*/false);
+else {
+#if LLDB_ENABLE_POSIX
+  socket = new DomainSocket(sockfd, /*should_close=*/true,
+/*child_processes_inherit=*/false);
+#else
+  LLDB_LOGF(log,
+"lldb-platform child: Unix domain sockets are not supported on 
"
+"this platform.");

labath wrote:

print to stderr instead?

https://github.com/llvm/llvm-project/pull/104238
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Fix assert frame recognizer for Ubuntu 22.04 (PR #109594)

[Jan Kratochvil via lldb-commits]

jankratochvil wrote:

> I did not add a testcase because it would require a specific glibc.

Does some standard testcase FAIL->PASS by this fix when the testsuite is being 
run on Ubuntu 22.04? If not could you write such a testcase which would 
FAIL->PASS only on Ubuntu 22.04?

https://github.com/llvm/llvm-project/pull/109594
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett updated 
https://github.com/llvm/llvm-project/pull/109427

>From cc4032e58217a01ff414b8d03866a1631f492df8 Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Fri, 20 Sep 2024 14:00:44 +0100
Subject: [PATCH 1/2] [lldb][docs] Resurrect the information on adding a new
 language

This got deleted in e078c9507c3abb4d9bb2265c366b26557880a3e3,
I presume accidentally, because it didn't have a corresponding rst
file for it.

So I've brought it back and converted it into Markdown. The content
remains accurate, from what I know at least.

It's a bit "now draw the rest of the owl" but if nothing else,
it gives you a bunch of important classes to go and research
as a starting point.

You can see the original content here:
https://github.com/llvm/llvm-project/blob/5d71fc5d7b5ffe2323418a09db6eddaf84d6c662/lldb/www/adding-language-support.html
---
 lldb/docs/index.rst  |  1 +
 lldb/docs/resources/addinglanguagesupport.md | 95 
 2 files changed, 96 insertions(+)
 create mode 100644 lldb/docs/resources/addinglanguagesupport.md

diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index d9b8e589eb2ac0..dd44a8430add80 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -163,6 +163,7 @@ interesting areas to contribute to lldb.
resources/caveats
resources/projects
resources/lldbdap
+   resources/addinglanguagesupport
Public C++ API 
Private C++ API 
 
diff --git a/lldb/docs/resources/addinglanguagesupport.md 
b/lldb/docs/resources/addinglanguagesupport.md
new file mode 100644
index 00..d92104a0e5e6ec
--- /dev/null
+++ b/lldb/docs/resources/addinglanguagesupport.md
@@ -0,0 +1,95 @@
+# Adding Programming Language Support
+
+LLDB has been architected to make it straightforward to add support for a
+programming language. Only a small enum in core LLDB needs to be modified to
+make LLDB aware of a new programming language. Everything else can be supplied
+in derived classes that need not even be present in the core LLDB repository.
+This makes it convenient for developers adding language support either in
+branches or downstream repositories since it practically eliminates the
+potential for merge conflicts.
+
+The basic steps are:
+* Add the language to the `LanguageType` enum.
+* Add a `TypeSystem` for the language.
+* Add expression evaluation support.
+
+Additionally, you may want to create a `Language` and `LanguageRuntime` plugin
+for your language, which enables support for advanced features like dynamic
+typing and data formatting.
+
+## Add the Language to the LanguageType enum
+
+The `LanguageType` enum
+(see 
[lldb-enumerations.h](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/lldb-enumerations.h))
+contains a list of every language known to LLDB. It is the one place where
+support for a language must live that will need to merge cleanly with upstream
+LLDB if you are developing your language support in a separate branch. When
+adding support for a language previously unknown to LLDB, start by adding an
+enumeration entry to `LanguageType`.
+
+## Add a TypeSystem for the Language
+
+Both 
[Module](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Core/Module.h)
+and 
[Target](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Target/Target.h)
+support the retrieval of a `TypeSystem` instance via 
`GetTypeSystemForLanguage()`.
+For `Module`, this method is directly on the `Module` instance. For `Target`,
+this is retrieved indirectly via the `TypeSystemMap` for the `Target` instance.
+
+The `TypeSystem` instance returned by the `Target` is expected to be capable of
+evaluating expressions, while the `TypeSystem` instance returned by the 
`Module`
+is not. If want to support expression evaluation for your language, you could
+consider one of the following approaches:
+* Implement a single `TypeSystem` class that supports evaluation when given an
+  optional `Target`, implementing all the expression evaluation methods on the
+  `TypeSystem`.
+* Create multiple `TypeSystem` classes, one for evaluation and one for static
+  `Module` usage.
+
+For clang and Swift, the latter approach was chosen. Primarily to make it
+clearer that evaluation with the static `Module`-returned `TypeSystem` 
instances
+make no sense, and have them error out on those calls. But either approach is
+fine.
+
+# Add Expression Evaluation Support
+
+Expression Evaluation support is enabled by implementing the relevant methods 
on
+a `TypeSystem`-derived class. Search for `Expression` in the
+[TypeSystem 
header](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Symbol/TypeSystem.h)
+to find the methods to implement.
+
+# Type Completion
+
+There are three levels of type completion, each requiring more type 
information:
+1. Pointer size: When you have a forward decl or a

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

[David Spickett via lldb-commits]

@@ -0,0 +1,95 @@
+# Adding Programming Language Support
+
+LLDB has been architected to make it straightforward to add support for a
+programming language. Only a small enum in core LLDB needs to be modified to
+make LLDB aware of a new programming language. Everything else can be supplied
+in derived classes that need not even be present in the core LLDB repository.
+This makes it convenient for developers adding language support either in
+branches or downstream repositories since it practically eliminates the
+potential for merge conflicts.
+
+The basic steps are:
+* Add the language to the `LanguageType` enum.
+* Add a `TypeSystem` for the language.
+* Add expression evaluation support.
+
+Additionally, you may want to create a `Language` and `LanguageRuntime` plugin
+for your language, which enables support for advanced features like dynamic
+typing and data formatting.
+
+## Add the Language to the LanguageType enum
+
+The `LanguageType` enum
+(see 
[lldb-enumerations.h](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/lldb-enumerations.h))
+contains a list of every language known to LLDB. It is the one place where
+support for a language must live that will need to merge cleanly with upstream
+LLDB if you are developing your language support in a separate branch. When
+adding support for a language previously unknown to LLDB, start by adding an
+enumeration entry to `LanguageType`.
+
+## Add a TypeSystem for the Language
+
+Both 
[Module](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Core/Module.h)
+and 
[Target](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Target/Target.h)
+support the retrieval of a `TypeSystem` instance via 
`GetTypeSystemForLanguage()`.
+For `Module`, this method is directly on the `Module` instance. For `Target`,
+this is retrieved indirectly via the `TypeSystemMap` for the `Target` instance.
+
+The `TypeSystem` instance returned by the `Target` is expected to be capable of
+evaluating expressions, while the `TypeSystem` instance returned by the 
`Module`
+is not. If want to support expression evaluation for your language, you could
+consider one of the following approaches:
+* Implement a single `TypeSystem` class that supports evaluation when given an
+  optional `Target`, implementing all the expression evaluation methods on the
+  `TypeSystem`.
+* Create multiple `TypeSystem` classes, one for evaluation and one for static
+  `Module` usage.
+
+For clang and Swift, the latter approach was chosen. Primarily to make it
+clearer that evaluation with the static `Module`-returned `TypeSystem` 
instances
+make no sense, and have them error out on those calls. But either approach is
+fine.
+
+# Add Expression Evaluation Support
+
+Expression Evaluation support is enabled by implementing the relevant methods 
on
+a `TypeSystem`-derived class. Search for `Expression` in the
+[TypeSystem 
header](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Symbol/TypeSystem.h)
+to find the methods to implement.
+
+# Type Completion
+
+There are three levels of type completion, each requiring more type 
information:
+1. Pointer size: When you have a forward decl or a reference, and that's all 
you
+  need. At this stage, the pointer size is all you need.
+2. Layout info: You need the size of an instance of the type, but you still 
don't
+  need to know all the guts of the type.
+3. Full type info: Here you need everything, because you're playing with
+  internals of it, such as modifying a member variable.
+
+Ensure you never complete more of a type than is needed for a given situation.
+This will keep your type system from doing more work than necessary.
+
+# Creating Types
+
+Your `TypeSystem` will need an approach for creating types based on a set of
+`Module`s. If your type info is going to come from DWARF info, you will want to
+subclass 
[DWARFASTParser](https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.h).
+
+# Language and LanguageRuntime Plugins
+
+If you followed the steps outlined above, you already have taught LLDB a great
+deal about your language. If your language's runtime model and fundamental data
+types don't differ much from the C model, you are pretty much done.
+
+However it is likely that your language offers its own data types for things
+like strings and arrays, and probably has a notion of dynamic types, where the
+effective type of a variable can only be known at runtime.
+
+These tasks are covered by two plugins:
+* a `LanguageRuntime` plugin, which provides LLDB with a dynamic view of your
+  language; this plugin answers questions that require a live process to 
acquire
+  information (for example dynamic type resolution).
+* a `Language plugin`, which provides LLDB with a static view of your language;
+  questions that are statically knoawble and do not require a process are

DavidSpickett wrote:

Done.

https://gith

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

[David Spickett via lldb-commits]

@@ -0,0 +1,95 @@
+# Adding Programming Language Support
+
+LLDB has been architected to make it straightforward to add support for a
+programming language. Only a small enum in core LLDB needs to be modified to
+make LLDB aware of a new programming language. Everything else can be supplied
+in derived classes that need not even be present in the core LLDB repository.
+This makes it convenient for developers adding language support either in
+branches or downstream repositories since it practically eliminates the
+potential for merge conflicts.
+
+The basic steps are:
+* Add the language to the `LanguageType` enum.
+* Add a `TypeSystem` for the language.
+* Add expression evaluation support.
+
+Additionally, you may want to create a `Language` and `LanguageRuntime` plugin
+for your language, which enables support for advanced features like dynamic
+typing and data formatting.
+
+## Add the Language to the LanguageType enum
+
+The `LanguageType` enum
+(see 
[lldb-enumerations.h](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/lldb-enumerations.h))
+contains a list of every language known to LLDB. It is the one place where
+support for a language must live that will need to merge cleanly with upstream
+LLDB if you are developing your language support in a separate branch. When
+adding support for a language previously unknown to LLDB, start by adding an
+enumeration entry to `LanguageType`.
+
+## Add a TypeSystem for the Language
+
+Both 
[Module](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Core/Module.h)
+and 
[Target](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Target/Target.h)
+support the retrieval of a `TypeSystem` instance via 
`GetTypeSystemForLanguage()`.
+For `Module`, this method is directly on the `Module` instance. For `Target`,
+this is retrieved indirectly via the `TypeSystemMap` for the `Target` instance.
+
+The `TypeSystem` instance returned by the `Target` is expected to be capable of
+evaluating expressions, while the `TypeSystem` instance returned by the 
`Module`
+is not. If want to support expression evaluation for your language, you could
+consider one of the following approaches:
+* Implement a single `TypeSystem` class that supports evaluation when given an
+  optional `Target`, implementing all the expression evaluation methods on the
+  `TypeSystem`.
+* Create multiple `TypeSystem` classes, one for evaluation and one for static
+  `Module` usage.
+
+For clang and Swift, the latter approach was chosen. Primarily to make it
+clearer that evaluation with the static `Module`-returned `TypeSystem` 
instances
+make no sense, and have them error out on those calls. But either approach is
+fine.
+
+# Add Expression Evaluation Support
+
+Expression Evaluation support is enabled by implementing the relevant methods 
on
+a `TypeSystem`-derived class. Search for `Expression` in the
+[TypeSystem 
header](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Symbol/TypeSystem.h)
+to find the methods to implement.
+
+# Type Completion
+
+There are three levels of type completion, each requiring more type 
information:
+1. Pointer size: When you have a forward decl or a reference, and that's all 
you
+  need. At this stage, the pointer size is all you need.
+2. Layout info: You need the size of an instance of the type, but you still 
don't
+  need to know all the guts of the type.
+3. Full type info: Here you need everything, because you're playing with
+  internals of it, such as modifying a member variable.
+
+Ensure you never complete more of a type than is needed for a given situation.
+This will keep your type system from doing more work than necessary.
+
+# Creating Types
+
+Your `TypeSystem` will need an approach for creating types based on a set of
+`Module`s. If your type info is going to come from DWARF info, you will want to
+subclass 
[DWARFASTParser](https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.h).
+
+# Language and LanguageRuntime Plugins
+
+If you followed the steps outlined above, you already have taught LLDB a great
+deal about your language. If your language's runtime model and fundamental data
+types don't differ much from the C model, you are pretty much done.
+
+However it is likely that your language offers its own data types for things
+like strings and arrays, and probably has a notion of dynamic types, where the
+effective type of a variable can only be known at runtime.
+
+These tasks are covered by two plugins:
+* a `LanguageRuntime` plugin, which provides LLDB with a dynamic view of your
+  language; this plugin answers questions that require a live process to 
acquire
+  information (for example dynamic type resolution).
+* a `Language plugin`, which provides LLDB with a static view of your language;

DavidSpickett wrote:

Done.

https://github.com/llvm/llvm-project/pull/109427
__

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

[David Spickett via lldb-commits]

@@ -0,0 +1,95 @@
+# Adding Programming Language Support
+
+LLDB has been architected to make it straightforward to add support for a
+programming language. Only a small enum in core LLDB needs to be modified to
+make LLDB aware of a new programming language. Everything else can be supplied
+in derived classes that need not even be present in the core LLDB repository.
+This makes it convenient for developers adding language support either in
+branches or downstream repositories since it practically eliminates the

DavidSpickett wrote:

I've removed it and only mentioned downstream repos.

https://github.com/llvm/llvm-project/pull/109427
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

[David Spickett via lldb-commits]

DavidSpickett wrote:

> I think this page leaves a lot to be desired but it's a good start.

Given that language support runs from:
* Pretend it's C++ and hope (Rust) to -
* Have an entire llvm fork (Swift).

The documentation is never going to be great, this is true. Next time a 
language is added we can at least record all the PRs in this document as an 
example, albeit one using the APIs of the time.

https://github.com/llvm/llvm-project/pull/109427
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

[Dmitry Vasilyev via lldb-commits]

slydiman wrote:

> But do both of those callers need the "optional launch" functionality? AIUI, 
> it's only the Handle_qLaunchGDBServer that does, and the code in 
> lldb-platform.cpp should launch a server unconditionally.

We can launch gdbserver with tcp protocol only after accepting the connection.
lldb-platform.cpp calls GDBRemoteCommunicationServerPlatform::LaunchGDBServer() 
when
1. Accept the gdb connection (fd is known).
2. At the beginning if additional parameters provided after `--`. 
fd=kInvalidFD. It is a `pending` GdbServer.

https://github.com/llvm/llvm-project/pull/104238
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 40d8888 - [lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)

[Adrian Prantl via lldb-commits]

Author: Adrian Prantl
Date: 2024-09-23T09:35:27-07:00
New Revision: 40df13fb54b0fe840deef23054de6544c184

URL: 
https://github.com/llvm/llvm-project/commit/40df13fb54b0fe840deef23054de6544c184
DIFF: 
https://github.com/llvm/llvm-project/commit/40df13fb54b0fe840deef23054de6544c184.diff

LOG: [lldb] Change the implementation of Status to store an llvm::Error (NFC) 
(#106774)

(based on a conversation I had with @labath yesterday in
https://github.com/llvm/llvm-project/pull/106442)

Most APIs that currently vend a Status would be better served by
returning llvm::Expected<> instead. If possibles APIs should be
refactored to avoid Status. The only legitimate long-term uses of Status
are objects that need to store an error for a long time (which should be
questioned as a design decision, too).

This patch makes the transition to llvm::Error easier by making the
places that cannot switch to llvm::Error explicit: They are marked with
a call to Status::clone(). Every other API can and should be refactored
to use llvm::Expected. In the end Status should only be used in very few
places.

Whenever an unchecked Error is dropped by Status it logs this to the
verbose API channel.

Implementation notes:

This patch introduces two new kinds of error_category as well as new
llvm::Error types. Here is the mapping of lldb::ErrorType to
llvm::Errors:
```
   (eErrorTypeInvalid)
   eErrorTypeGeneric  llvm::StringError
   eErrorTypePOSIXllvm::ECError
   eErrorTypeMachKernel   MachKernelError
   eErrorTypeExpression   llvm::ErrorList
   eErrorTypeWin32Win32Error
```

Relanding with built-in cloning support for llvm::ECError, and support
for initializing a Windows error with a NO_ERROR error code.

Added: 


Modified: 
lldb/include/lldb/Utility/Status.h
lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
lldb/source/Utility/Status.cpp
lldb/unittests/Utility/StatusTest.cpp

Removed: 




diff  --git a/lldb/include/lldb/Utility/Status.h 
b/lldb/include/lldb/Utility/Status.h
index 795c830b965173..084ce4afb8cefd 100644
--- a/lldb/include/lldb/Utility/Status.h
+++ b/lldb/include/lldb/Utility/Status.h
@@ -28,6 +28,67 @@ namespace lldb_private {
 
 const char *ExpressionResultAsCString(lldb::ExpressionResults result);
 
+/// Going a bit against the spirit of llvm::Error,
+/// lldb_private::Status need to store errors long-term and sometimes
+/// copy them. This base class defines an interface for this
+/// operation.
+class CloneableError
+: public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  CloneableError() : ErrorInfo() {}
+  virtual std::unique_ptr Clone() const = 0;
+  static char ID;
+};
+
+/// Common base class for all error-code errors.
+class CloneableECError
+: public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  std::error_code convertToErrorCode() const override { return EC; }
+  void log(llvm::raw_ostream &OS) const override { OS << EC.message(); }
+  static char ID;
+
+protected:
+  CloneableECError() = delete;
+  CloneableECError(std::error_code ec) : ErrorInfo(), EC(ec) {}
+  std::error_code EC;
+};
+/// FIXME: Move these declarations closer to where they're used.
+class MachKernelError
+: public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  MachKernelError(std::error_code ec) : ErrorInfo(ec) {}
+  std::string message() const override;
+  std::unique_ptr Clone() const override;
+  static char ID;
+};
+
+class Win32Error : public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  Win32Error(std::error_code ec, const llvm::Twine &msg = {}) : ErrorInfo(ec) 
{}
+  std::string message() const override;
+  std::unique_ptr Clone() const override;
+  static char ID;
+};
+
+class ExpressionError
+: public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  ExpressionError(std::error_code ec, std::string msg = {})
+  : ErrorInfo(ec), m_string(msg) {}
+  std::unique_ptr Clone() const override;
+  std::string message() const override { return m_string; }
+  static char ID;
+
+protected:
+  std::string m_string;
+};
+
 /// \class Status Status.h "lldb/Utility/Status.h" An error handling class.
 ///
 /// This class is designed to be able to hold any error code that can be
@@ -100,9 +161,7 @@ class Status {
   }
 
   static Status FromExpressionError(lldb::ExpressionResults result,
-std::string msg) {
-return Status(result, lldb::eErrorTypeExpression, msg);
-  }
+std::string msg);
 
   /// Set the current error to errno.
   ///
@@ -115,6 +174,7 @@ class Status {
   const Status &operator=(Status &&);
   /// Avoid using this in new code. Migrate APIs to llvm::Expected instead.
   static Status FromError(llvm::Error error);
+
   /// FIXME: Replace this with a takeError() method.
   llvm::Error ToError()

[Lldb-commits] [lldb] Improve type and namespace lookup using parent chain (PR #108907)

[Felipe de Azevedo Piovezan via lldb-commits]

@@ -402,6 +420,36 @@ bool DebugNamesDWARFIndex::SameParentChain(
   return true;
 }
 
+bool DebugNamesDWARFIndex::WithinParentChain(
+llvm::ArrayRef query_parent_names,
+llvm::ArrayRef parent_chain) const {
+  if (parent_chain.size() < query_parent_names.size())
+return false;
+
+  size_t query_idx = 0, chain_idx = 0;
+  while (query_idx < query_parent_names.size() &&
+ chain_idx < parent_chain.size()) {
+if (SameAsEntryATName(query_parent_names[query_idx],
+  parent_chain[chain_idx])) {
+  ++query_idx;
+  ++chain_idx;
+} else {
+  // Name does not match, try next parent_chain entry if the current entry
+  // is namespace because the current one can be an inline namespace.

felipepiovezan wrote:

Ok, good to know we have a mechanism to detect inline namespaces.

That still leaves the question of how to avoid false results though. I 
understand peeking at the DIE would be expensive for `dwo`s, but I don't think 
we can sacrifice the correctness of the answer for these queries. One 
possibility to explore is to add another IDX entry for namespaces, which would 
include whether they export symbols or not.

https://github.com/llvm/llvm-project/pull/108907
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 97b0d20 - Revert "[lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)"

[Adrian Prantl via lldb-commits]

Author: Adrian Prantl
Date: 2024-09-23T10:50:51-07:00
New Revision: 97b0d2076f53f669f27dc6d0539a3d01f28381e7

URL: 
https://github.com/llvm/llvm-project/commit/97b0d2076f53f669f27dc6d0539a3d01f28381e7
DIFF: 
https://github.com/llvm/llvm-project/commit/97b0d2076f53f669f27dc6d0539a3d01f28381e7.diff

LOG: Revert "[lldb] Change the implementation of Status to store an llvm::Error 
(NFC) (#106774)"

This reverts commit 40df13fb54b0fe840deef23054de6544c184.
One last Windows failure remaining.

Added: 


Modified: 
lldb/include/lldb/Utility/Status.h
lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
lldb/source/Utility/Status.cpp
lldb/unittests/Utility/StatusTest.cpp

Removed: 




diff  --git a/lldb/include/lldb/Utility/Status.h 
b/lldb/include/lldb/Utility/Status.h
index 084ce4afb8cefd..795c830b965173 100644
--- a/lldb/include/lldb/Utility/Status.h
+++ b/lldb/include/lldb/Utility/Status.h
@@ -28,67 +28,6 @@ namespace lldb_private {
 
 const char *ExpressionResultAsCString(lldb::ExpressionResults result);
 
-/// Going a bit against the spirit of llvm::Error,
-/// lldb_private::Status need to store errors long-term and sometimes
-/// copy them. This base class defines an interface for this
-/// operation.
-class CloneableError
-: public llvm::ErrorInfo {
-public:
-  using llvm::ErrorInfo::ErrorInfo;
-  CloneableError() : ErrorInfo() {}
-  virtual std::unique_ptr Clone() const = 0;
-  static char ID;
-};
-
-/// Common base class for all error-code errors.
-class CloneableECError
-: public llvm::ErrorInfo {
-public:
-  using llvm::ErrorInfo::ErrorInfo;
-  std::error_code convertToErrorCode() const override { return EC; }
-  void log(llvm::raw_ostream &OS) const override { OS << EC.message(); }
-  static char ID;
-
-protected:
-  CloneableECError() = delete;
-  CloneableECError(std::error_code ec) : ErrorInfo(), EC(ec) {}
-  std::error_code EC;
-};
-/// FIXME: Move these declarations closer to where they're used.
-class MachKernelError
-: public llvm::ErrorInfo {
-public:
-  using llvm::ErrorInfo::ErrorInfo;
-  MachKernelError(std::error_code ec) : ErrorInfo(ec) {}
-  std::string message() const override;
-  std::unique_ptr Clone() const override;
-  static char ID;
-};
-
-class Win32Error : public llvm::ErrorInfo {
-public:
-  using llvm::ErrorInfo::ErrorInfo;
-  Win32Error(std::error_code ec, const llvm::Twine &msg = {}) : ErrorInfo(ec) 
{}
-  std::string message() const override;
-  std::unique_ptr Clone() const override;
-  static char ID;
-};
-
-class ExpressionError
-: public llvm::ErrorInfo {
-public:
-  using llvm::ErrorInfo::ErrorInfo;
-  ExpressionError(std::error_code ec, std::string msg = {})
-  : ErrorInfo(ec), m_string(msg) {}
-  std::unique_ptr Clone() const override;
-  std::string message() const override { return m_string; }
-  static char ID;
-
-protected:
-  std::string m_string;
-};
-
 /// \class Status Status.h "lldb/Utility/Status.h" An error handling class.
 ///
 /// This class is designed to be able to hold any error code that can be
@@ -161,7 +100,9 @@ class Status {
   }
 
   static Status FromExpressionError(lldb::ExpressionResults result,
-std::string msg);
+std::string msg) {
+return Status(result, lldb::eErrorTypeExpression, msg);
+  }
 
   /// Set the current error to errno.
   ///
@@ -174,7 +115,6 @@ class Status {
   const Status &operator=(Status &&);
   /// Avoid using this in new code. Migrate APIs to llvm::Expected instead.
   static Status FromError(llvm::Error error);
-
   /// FIXME: Replace this with a takeError() method.
   llvm::Error ToError() const;
   /// Don't call this function in new code. Instead, redesign the API
@@ -209,20 +149,12 @@ class Status {
 
   /// Access the error value.
   ///
-  /// If the internally stored \ref llvm::Error is an \ref
-  /// llvm::ErrorList then this returns the error value of the first
-  /// error.
-  ///
   /// \return
   /// The error value.
   ValueType GetError() const;
 
   /// Access the error type.
   ///
-  /// If the internally stored \ref llvm::Error is an \ref
-  /// llvm::ErrorList then this returns the error value of the first
-  /// error.
-  ///
   /// \return
   /// The error type enumeration value.
   lldb::ErrorType GetType() const;
@@ -238,9 +170,12 @@ class Status {
   bool Success() const;
 
 protected:
-  Status(llvm::Error error) : m_error(std::move(error)) {}
-  llvm::Error m_error;
-  /// TODO: Replace this with just calling toString(m_error).
+  Status(llvm::Error error);
+  /// Status code as an integer value.
+  ValueType m_code = 0;
+  /// The type of the above error code.
+  lldb::ErrorType m_type = lldb::eErrorTypeInvalid;
+  /// A string representation of the error code.
   mutable std::string m_string;
 };
 

diff  --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/PythonDat

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

[Walter Erquinigo via lldb-commits]

https://github.com/walter-erquinigo approved this pull request.

beautiful. 

https://github.com/llvm/llvm-project/pull/109427
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][NFC] New names for the two RegisterLocation classes (PR #109611)

[Jason Molenda via lldb-commits]

https://github.com/jasonmolenda closed 
https://github.com/llvm/llvm-project/pull/109611
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][AArch64] Create Neon subregs when XML only includes SVE (PR #108365)

[Jason Molenda via lldb-commits]

https://github.com/jasonmolenda approved this pull request.

I read through the patch, this looks good to me.

https://github.com/llvm/llvm-project/pull/108365
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 3336d73 - [lldb][NFC] New names for the two RegisterLocation classes (#109611)

[via lldb-commits]

Author: Jason Molenda
Date: 2024-09-23T10:29:21-07:00
New Revision: 3336d73126ae7ebaadf7c3a4d85e373eaae8cda6

URL: 
https://github.com/llvm/llvm-project/commit/3336d73126ae7ebaadf7c3a4d85e373eaae8cda6
DIFF: 
https://github.com/llvm/llvm-project/commit/3336d73126ae7ebaadf7c3a4d85e373eaae8cda6.diff

LOG: [lldb][NFC] New names for the two RegisterLocation classes (#109611)

lldb has two RegisterLocation classes that do slightly different things.

UnwindPlan::Row::RegisterLocation (new: AbstractRegisterLocation) has a
description of how to find a register's value or location, not specific
to a particular stopping point. It may say that at a given offset into a
function, the caller's register has been spilled to stack memory at CFA
minus an offset. Or it may say that the caller's register is at a DWARF
exprssion.

UnwindLLDB::RegisterLocation (new: ConcreteRegisterLocation) is a
specific address where the register is currently stored, or the register
it has been copied into, or its value at this point in the current
function execution.

When lldb stops in a function, it interprets the
AbstractRegisterLocation's instructions using the register context and
stack memory, to create the ConcreteRegisterLocation at this point in
time for this stack frame.

I'm not thrilled with AbstractRegisterLocation and
ConcreteRegisterLocation, but it's better than the same name and it will
be easier to update them if someone suggests a better pair.

Added: 


Modified: 
lldb/include/lldb/Symbol/UnwindPlan.h
lldb/include/lldb/Target/ABI.h
lldb/include/lldb/Target/RegisterContextUnwind.h
lldb/include/lldb/Target/UnwindLLDB.h
lldb/source/Plugins/ABI/SystemZ/ABISysV_s390x.cpp
lldb/source/Plugins/ABI/SystemZ/ABISysV_s390x.h
lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp
lldb/source/Plugins/UnwindAssembly/x86/UnwindAssembly-x86.cpp
lldb/source/Plugins/UnwindAssembly/x86/x86AssemblyInspectionEngine.cpp
lldb/source/Symbol/ArmUnwindInfo.cpp
lldb/source/Symbol/DWARFCallFrameInfo.cpp
lldb/source/Symbol/FuncUnwinders.cpp
lldb/source/Symbol/UnwindPlan.cpp
lldb/source/Target/ABI.cpp
lldb/source/Target/RegisterContextUnwind.cpp
lldb/source/Target/UnwindLLDB.cpp
lldb/unittests/UnwindAssembly/ARM64/TestArm64InstEmulation.cpp
lldb/unittests/UnwindAssembly/PPC64/TestPPC64InstEmulation.cpp
lldb/unittests/UnwindAssembly/x86/Testx86AssemblyInspectionEngine.cpp

Removed: 




diff  --git a/lldb/include/lldb/Symbol/UnwindPlan.h 
b/lldb/include/lldb/Symbol/UnwindPlan.h
index a9e8406608ff31..a1d00f2d2c0cd1 100644
--- a/lldb/include/lldb/Symbol/UnwindPlan.h
+++ b/lldb/include/lldb/Symbol/UnwindPlan.h
@@ -54,7 +54,7 @@ class UnwindPlan {
 public:
   class Row {
   public:
-class RegisterLocation {
+class AbstractRegisterLocation {
 public:
   enum RestoreType {
 unspecified,   // not specified, we may be able to assume this
@@ -72,11 +72,11 @@ class UnwindPlan {
 isConstant // reg = constant
   };
 
-  RegisterLocation() : m_location() {}
+  AbstractRegisterLocation() : m_location() {}
 
-  bool operator==(const RegisterLocation &rhs) const;
+  bool operator==(const AbstractRegisterLocation &rhs) const;
 
-  bool operator!=(const RegisterLocation &rhs) const {
+  bool operator!=(const AbstractRegisterLocation &rhs) const {
 return !(*this == rhs);
   }
 
@@ -337,10 +337,10 @@ class UnwindPlan {
 bool operator==(const Row &rhs) const;
 
 bool GetRegisterInfo(uint32_t reg_num,
- RegisterLocation ®ister_location) const;
+ AbstractRegisterLocation ®ister_location) const;
 
 void SetRegisterInfo(uint32_t reg_num,
- const RegisterLocation register_location);
+ const AbstractRegisterLocation register_location);
 
 void RemoveRegisterInfo(uint32_t reg_num);
 
@@ -398,7 +398,7 @@ class UnwindPlan {
   lldb::addr_t base_addr) const;
 
   protected:
-typedef std::map collection;
+typedef std::map collection;
 lldb::addr_t m_offset = 0; // Offset into the function for this row
 
 FAValue m_cfa_value;

diff  --git a/lldb/include/lldb/Target/ABI.h b/lldb/include/lldb/Target/ABI.h
index 7b646d743346b7..dd941d1c905c15 100644
--- a/lldb/include/lldb/Target/ABI.h
+++ b/lldb/include/lldb/Target/ABI.h
@@ -102,9 +102,9 @@ class ABI : public PluginInterface {
 
   virtual bool RegisterIsVolatile(const RegisterInfo *reg_info) = 0;
 
-  virtual bool
-  GetFallbackRegisterLocation(const RegisterInfo *reg_info,
-  UnwindPlan::Row::RegisterLocation 
&unwind_regloc);
+  virtual bool GetFallbackRegisterLocation(
+  const RegisterInfo *reg_info,
+  UnwindPlan::Row::AbstractRegisterLocation &unwind_regloc);
 
   // Should take a look at a call frame addr

[Lldb-commits] [lldb] [lldb] Don't invalid register context after setting thread pc's (PR #109499)

[Jason Molenda via lldb-commits]

jasonmolenda wrote:

> What's the exact situation that triggered these extra packets. Could it be 
> simulated from a gdb-remote client test (i.e., by mocking server responses)?

We've always done it when we step over our dynamic loader notification 
breakpoint (when new solibs are loaded and lldb is informed), I think it 
depends on the ordering that we invoke these methods in ProcessGDBRemote, I 
didn't try to debug what shifted in our call ordering to make this become a 
hotter problem recently.

(that's why my test case dlopen's a solib, because that was a specific issue)

https://github.com/llvm/llvm-project/pull/109499
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Fix assert frame recognizer for Ubuntu 22.04 (PR #109594)

[Adrian Vogelsgesang via lldb-commits]

vogelsgesang wrote:

I just realized that this was previously mentioned in #56144. The comments on 
that item make me wonder if this commit here actually even uses the right 
approach... Should I instead extend the recognizer framework to also match on 
the non-topmost frame?

https://github.com/llvm/llvm-project/pull/109594
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB][Minidump] Have Minidumps save off and properly read TLS data (PR #109477)

[Jacob Lalonde via lldb-commits]

Jlalond wrote:

@labath I really like the idea to add the TLS saving to the dynamic loader, 
I'll add that, 

As for the dynamic loader, I don't like how I've modified it. When a minidump 
is loaded, the link map isn't properly relocated, so TLS data is searched for 
relative to module lowest in memory. 

So for my example, we were looking for TLS data in `ef...` when the TLS 
section in the live process was in the relocated module at `777f... `. Forcing 
the POSIX DYLD to rebase them worked, but it's at best a hack.

[This 
codepath](https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp#L118)
 results in none of the modules being loaded, or rebased, and I don't why this 
should apply without checking all modules.

https://github.com/llvm/llvm-project/pull/109477
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Fix assert frame recognizer for Ubuntu 22.04 (PR #109594)

[Adrian Vogelsgesang via lldb-commits]

vogelsgesang wrote:

CC @labath since you aparrently already put some thoughts into this 2 years 
ago, when opening #56144 

https://github.com/llvm/llvm-project/pull/109594
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

[Dmitry Vasilyev via lldb-commits]

https://github.com/slydiman updated 
https://github.com/llvm/llvm-project/pull/104238

>From 792cb17f05ded47b152408ac7f4d1de6c986013f Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev 
Date: Fri, 6 Sep 2024 16:12:50 +0400
Subject: [PATCH 1/4] [lldb] Removed gdbserver ports map from lldb-server

Listen to gdbserver-port, accept the connection and run lldb-server gdbserver 
--fd on all platforms.
Parameters --min-gdbserver-port and --max-gdbserver-port are deprecated now.

This is the part 2 of #101283.

Fixes #97537, fixes #101475.
---
 lldb/docs/man/lldb-server.rst |  11 +-
 lldb/docs/resources/qemu-testing.rst  |  19 +-
 .../GDBRemoteCommunicationServerPlatform.cpp  | 287 +
 .../GDBRemoteCommunicationServerPlatform.h|  82 +---
 .../TestPlatformLaunchGDBServer.py|  12 +-
 .../Shell/lldb-server/TestGdbserverPort.test  |   4 -
 lldb/tools/lldb-server/Acceptor.cpp   |  98 -
 lldb/tools/lldb-server/Acceptor.h |  60 ---
 lldb/tools/lldb-server/CMakeLists.txt |   1 -
 lldb/tools/lldb-server/lldb-gdbserver.cpp |  17 +-
 lldb/tools/lldb-server/lldb-platform.cpp  | 391 --
 .../Process/gdb-remote/CMakeLists.txt |   1 -
 .../Process/gdb-remote/PortMapTest.cpp| 115 --
 13 files changed, 391 insertions(+), 707 deletions(-)
 delete mode 100644 lldb/test/Shell/lldb-server/TestGdbserverPort.test
 delete mode 100644 lldb/tools/lldb-server/Acceptor.cpp
 delete mode 100644 lldb/tools/lldb-server/Acceptor.h
 delete mode 100644 lldb/unittests/Process/gdb-remote/PortMapTest.cpp

diff --git a/lldb/docs/man/lldb-server.rst b/lldb/docs/man/lldb-server.rst
index a67c00b305f6d2..31f5360df5e23e 100644
--- a/lldb/docs/man/lldb-server.rst
+++ b/lldb/docs/man/lldb-server.rst
@@ -147,15 +147,8 @@ GDB-SERVER CONNECTIONS
 
 .. option:: --gdbserver-port 
 
- Define a port to be used for gdb-server connections. Can be specified multiple
- times to allow multiple ports. Has no effect if --min-gdbserver-port
- and --max-gdbserver-port are specified.
-
-.. option:: --min-gdbserver-port 
-.. option:: --max-gdbserver-port 
-
- Specify the range of ports that can be used for gdb-server connections. Both
- options need to be specified simultaneously. Overrides --gdbserver-port.
+ Define a port to be used for gdb-server connections. This port is used for
+ multiple connections.
 
 .. option:: --port-offset 
 
diff --git a/lldb/docs/resources/qemu-testing.rst 
b/lldb/docs/resources/qemu-testing.rst
index 51a30b11717a87..e102f84a1d31f4 100644
--- a/lldb/docs/resources/qemu-testing.rst
+++ b/lldb/docs/resources/qemu-testing.rst
@@ -149,7 +149,6 @@ to the host (refer to QEMU's manuals for the specific 
options).
 * At least one to connect to the intial ``lldb-server``.
 * One more if you want to use ``lldb-server`` in ``platform mode``, and have it
   start a ``gdbserver`` instance for you.
-* A bunch more if you want to run tests against the ``lldb-server`` platform.
 
 If you are doing either of the latter 2 you should also restrict what ports
 ``lldb-server tries`` to use, otherwise it will randomly pick one that is 
almost
@@ -157,22 +156,14 @@ certainly not forwarded. An example of this is shown 
below.
 
 ::
 
-  $ lldb-server plaform --server --listen 0.0.0.0:54321 \
---min-gdbserver-port 49140 --max-gdbserver-port 49150
+  $ lldb-server plaform --server --listen 0.0.0.0:54321 --gdbserver-port 49140
 
 The result of this is that:
 
 * ``lldb-server`` platform mode listens externally on port ``54321``.
 
-* When it is asked to start a new gdbserver mode instance, it will use a port
-  in the range ``49140`` to ``49150``.
+* When it is asked to start a new gdbserver mode instance, it will use the port
+  ``49140``.
 
-Your VM configuration should have ports ``54321``, and ``49140`` to ``49150``
-forwarded for this to work.
-
-.. note::
-  These options are used to create a "port map" within ``lldb-server``.
-  Unfortunately this map is not cleaned up on Windows on connection close,
-  and across a few uses you may run out of valid ports. To work around this,
-  restart the platform every so often, especially after running a set of tests.
-  This is tracked here: https://github.com/llvm/llvm-project/issues/90923
+Your VM configuration should have ports ``54321`` and ``49140`` forwarded for
+this to work.
diff --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp
 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp
index c60a83d351ba09..647130b2984aac 100644
--- 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp
+++ 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp
@@ -44,79 +44,14 @@ using namespace lldb;
 using namespace lldb_private::process_gdb_remote;
 using namespace lldb_private;
 
-GDBRemoteCommunicationServerPlatform::PortMap::PortMap(uint16_t min_port,
-   

[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

[Dmitry Vasilyev via lldb-commits]

@@ -393,125 +362,222 @@ int main_platform(int argc, char *argv[]) {
   lldb_private::Args inferior_arguments;
   inferior_arguments.SetArguments(argc, const_cast(argv));
 
+  Socket::SocketProtocol protocol = Socket::ProtocolUnixDomain;
+
   if (fd != SharedSocket::kInvalidFD) {
 // Child process will handle the connection and exit.
+if (gdbserver_port)
+  protocol = Socket::ProtocolTcp;
+
 Log *log = GetLog(LLDBLog::Platform);
-if (!listen_host_port.empty()) {
-  LLDB_LOGF(log, "lldb-platform child: "
- "ambiguous parameters --listen and --child-platform-fd");
-  return socket_error;
-}
 
-NativeSocket socket;
-error = SharedSocket::GetNativeSocket(fd, socket);
+NativeSocket sockfd;
+error = SharedSocket::GetNativeSocket(fd, sockfd);
 if (error.Fail()) {
   LLDB_LOGF(log, "lldb-platform child: %s", error.AsCString());
   return socket_error;
 }
 
-GDBRemoteCommunicationServerPlatform platform(Socket::ProtocolTcp, "tcp");
-if (port_offset > 0)
-  platform.SetPortOffset(port_offset);
-platform.SetPortMap(std::move(gdbserver_portmap));
+GDBRemoteCommunicationServerPlatform platform(protocol, gdbserver_port);
+Socket *socket;
+if (protocol == Socket::ProtocolTcp)
+  socket = new TCPSocket(sockfd, /*should_close=*/true,
+ /*child_processes_inherit=*/false);
+else {
+#if LLDB_ENABLE_POSIX
+  socket = new DomainSocket(sockfd, /*should_close=*/true,
+/*child_processes_inherit=*/false);
+#else
+  LLDB_LOGF(log,
+"lldb-platform child: Unix domain sockets are not supported on 
"
+"this platform.");

slydiman wrote:

Probably you will never see that in stderr because it is a child process. But 
ok. Updated.

https://github.com/llvm/llvm-project/pull/104238
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

[Dmitry Vasilyev via lldb-commits]

@@ -393,125 +362,222 @@ int main_platform(int argc, char *argv[]) {
   lldb_private::Args inferior_arguments;
   inferior_arguments.SetArguments(argc, const_cast(argv));
 
+  Socket::SocketProtocol protocol = Socket::ProtocolUnixDomain;
+
   if (fd != SharedSocket::kInvalidFD) {
 // Child process will handle the connection and exit.
+if (gdbserver_port)
+  protocol = Socket::ProtocolTcp;
+
 Log *log = GetLog(LLDBLog::Platform);
-if (!listen_host_port.empty()) {
-  LLDB_LOGF(log, "lldb-platform child: "
- "ambiguous parameters --listen and --child-platform-fd");
-  return socket_error;
-}
 
-NativeSocket socket;
-error = SharedSocket::GetNativeSocket(fd, socket);
+NativeSocket sockfd;
+error = SharedSocket::GetNativeSocket(fd, sockfd);
 if (error.Fail()) {
   LLDB_LOGF(log, "lldb-platform child: %s", error.AsCString());
   return socket_error;
 }
 
-GDBRemoteCommunicationServerPlatform platform(Socket::ProtocolTcp, "tcp");
-if (port_offset > 0)
-  platform.SetPortOffset(port_offset);
-platform.SetPortMap(std::move(gdbserver_portmap));
+GDBRemoteCommunicationServerPlatform platform(protocol, gdbserver_port);
+Socket *socket;
+if (protocol == Socket::ProtocolTcp)
+  socket = new TCPSocket(sockfd, /*should_close=*/true,
+ /*child_processes_inherit=*/false);
+else {
+#if LLDB_ENABLE_POSIX
+  socket = new DomainSocket(sockfd, /*should_close=*/true,
+/*child_processes_inherit=*/false);
+#else
+  LLDB_LOGF(log,
+"lldb-platform child: Unix domain sockets are not supported on 
"
+"this platform.");
+  return socket_error;
+#endif
+}
 platform.SetConnection(
-std::unique_ptr(new ConnectionFileDescriptor(
-new TCPSocket(socket, /*should_close=*/true,
-  /*child_processes_inherit=*/false;
+std::unique_ptr(new ConnectionFileDescriptor(socket)));
 client_handle(platform, inferior_arguments);
 return 0;
   }
 
-  const bool children_inherit_listen_socket = false;
-  // the test suite makes many connections in parallel, let's not miss any.
-  // The highest this should get reasonably is a function of the number
-  // of target CPUs. For now, let's just use 100.
-  const int backlog = 100;
+  if (gdbserver_port != 0 &&
+  (gdbserver_port < LOW_PORT || gdbserver_port > HIGH_PORT)) {
+WithColor::error() << llvm::formatv("Port number {0} is not in the "
+"valid user port range of {1} - {2}\n",
+gdbserver_port, LOW_PORT, HIGH_PORT);
+return 1;
+  }
 
-  std::unique_ptr acceptor_up(Acceptor::Create(
-  listen_host_port, children_inherit_listen_socket, error));
-  if (error.Fail()) {
-fprintf(stderr, "failed to create acceptor: %s", error.AsCString());
-exit(socket_error);
+  std::string hostname;
+  uint16_t platform_port = 0;
+
+  // Try to match socket name as URL - e.g., tcp://localhost:
+  if (std::optional uri = URI::Parse(listen_host_port)) {
+if (!Socket::FindProtocolByScheme(uri->scheme.str().c_str(), protocol)) {
+  fprintf(stderr, "Unknown protocol scheme \"%s\".",
+  uri->scheme.str().c_str());
+  return socket_error;
+}
+if (protocol == Socket::ProtocolTcp) {
+  hostname = uri->hostname;
+  if (uri->port) {
+platform_port = *(uri->port);
+  }
+} else
+  hostname = listen_host_port.substr(uri->scheme.size() + strlen("://"));
+  } else {
+// Try to match socket name as $host:port - e.g., localhost:
+llvm::Expected host_port =
+Socket::DecodeHostAndPort(listen_host_port);
+if (!llvm::errorToBool(host_port.takeError())) {
+  protocol = Socket::ProtocolTcp;
+  hostname = host_port->hostname;
+  platform_port = host_port->port;
+} else
+  hostname = listen_host_port;
   }
 
-  error = acceptor_up->Listen(backlog);
+  if (protocol == Socket::ProtocolTcp) {
+if (platform_port != 0 && platform_port == gdbserver_port) {
+  fprintf(stderr, "The same platform and gdb ports %u.", platform_port);
+  return socket_error;
+}
+  } else {
+if (gdbserver_port) {
+  fprintf(stderr,
+  "--gdbserver-port %u is redundant for non-tcp protocol %s.",
+  gdbserver_port, Socket::FindSchemeByProtocol(protocol));
+  return socket_error;
+}
+if (g_server) {
+  fprintf(stderr,
+  "Ambiguous parameters --server --listen %s.\n"
+  "The protocol must be tcp for the server mode.",
+  listen_host_port.c_str());
+  return socket_error;
+}
+  }
+
+  std::unique_ptr sock_platform =
+  Socket::Create(protocol, /*child_processes_inherit=*/false, error);
+  if (error.Fail()) {
+printf("Failed to create platform socket: %s\n", err

[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

[Dmitry Vasilyev via lldb-commits]

@@ -393,125 +362,222 @@ int main_platform(int argc, char *argv[]) {
   lldb_private::Args inferior_arguments;
   inferior_arguments.SetArguments(argc, const_cast(argv));
 
+  Socket::SocketProtocol protocol = Socket::ProtocolUnixDomain;
+
   if (fd != SharedSocket::kInvalidFD) {
 // Child process will handle the connection and exit.
+if (gdbserver_port)
+  protocol = Socket::ProtocolTcp;
+
 Log *log = GetLog(LLDBLog::Platform);
-if (!listen_host_port.empty()) {
-  LLDB_LOGF(log, "lldb-platform child: "
- "ambiguous parameters --listen and --child-platform-fd");
-  return socket_error;
-}
 
-NativeSocket socket;
-error = SharedSocket::GetNativeSocket(fd, socket);
+NativeSocket sockfd;
+error = SharedSocket::GetNativeSocket(fd, sockfd);
 if (error.Fail()) {
   LLDB_LOGF(log, "lldb-platform child: %s", error.AsCString());
   return socket_error;
 }
 
-GDBRemoteCommunicationServerPlatform platform(Socket::ProtocolTcp, "tcp");
-if (port_offset > 0)
-  platform.SetPortOffset(port_offset);
-platform.SetPortMap(std::move(gdbserver_portmap));
+GDBRemoteCommunicationServerPlatform platform(protocol, gdbserver_port);
+Socket *socket;
+if (protocol == Socket::ProtocolTcp)
+  socket = new TCPSocket(sockfd, /*should_close=*/true,
+ /*child_processes_inherit=*/false);
+else {
+#if LLDB_ENABLE_POSIX
+  socket = new DomainSocket(sockfd, /*should_close=*/true,
+/*child_processes_inherit=*/false);
+#else
+  LLDB_LOGF(log,
+"lldb-platform child: Unix domain sockets are not supported on 
"
+"this platform.");
+  return socket_error;
+#endif
+}
 platform.SetConnection(
-std::unique_ptr(new ConnectionFileDescriptor(
-new TCPSocket(socket, /*should_close=*/true,
-  /*child_processes_inherit=*/false;
+std::unique_ptr(new ConnectionFileDescriptor(socket)));
 client_handle(platform, inferior_arguments);
 return 0;
   }
 
-  const bool children_inherit_listen_socket = false;
-  // the test suite makes many connections in parallel, let's not miss any.
-  // The highest this should get reasonably is a function of the number
-  // of target CPUs. For now, let's just use 100.
-  const int backlog = 100;
+  if (gdbserver_port != 0 &&
+  (gdbserver_port < LOW_PORT || gdbserver_port > HIGH_PORT)) {
+WithColor::error() << llvm::formatv("Port number {0} is not in the "
+"valid user port range of {1} - {2}\n",
+gdbserver_port, LOW_PORT, HIGH_PORT);
+return 1;
+  }
 
-  std::unique_ptr acceptor_up(Acceptor::Create(
-  listen_host_port, children_inherit_listen_socket, error));
-  if (error.Fail()) {
-fprintf(stderr, "failed to create acceptor: %s", error.AsCString());
-exit(socket_error);
+  std::string hostname;
+  uint16_t platform_port = 0;
+
+  // Try to match socket name as URL - e.g., tcp://localhost:
+  if (std::optional uri = URI::Parse(listen_host_port)) {
+if (!Socket::FindProtocolByScheme(uri->scheme.str().c_str(), protocol)) {
+  fprintf(stderr, "Unknown protocol scheme \"%s\".",
+  uri->scheme.str().c_str());
+  return socket_error;
+}
+if (protocol == Socket::ProtocolTcp) {
+  hostname = uri->hostname;
+  if (uri->port) {
+platform_port = *(uri->port);
+  }
+} else
+  hostname = listen_host_port.substr(uri->scheme.size() + strlen("://"));
+  } else {
+// Try to match socket name as $host:port - e.g., localhost:
+llvm::Expected host_port =
+Socket::DecodeHostAndPort(listen_host_port);
+if (!llvm::errorToBool(host_port.takeError())) {
+  protocol = Socket::ProtocolTcp;
+  hostname = host_port->hostname;
+  platform_port = host_port->port;
+} else
+  hostname = listen_host_port;
   }
 
-  error = acceptor_up->Listen(backlog);
+  if (protocol == Socket::ProtocolTcp) {
+if (platform_port != 0 && platform_port == gdbserver_port) {
+  fprintf(stderr, "The same platform and gdb ports %u.", platform_port);
+  return socket_error;
+}
+  } else {
+if (gdbserver_port) {
+  fprintf(stderr,
+  "--gdbserver-port %u is redundant for non-tcp protocol %s.",
+  gdbserver_port, Socket::FindSchemeByProtocol(protocol));
+  return socket_error;
+}
+if (g_server) {
+  fprintf(stderr,
+  "Ambiguous parameters --server --listen %s.\n"
+  "The protocol must be tcp for the server mode.",
+  listen_host_port.c_str());
+  return socket_error;

slydiman wrote:

I don't know how it works. But ok. Removed.

https://github.com/llvm/llvm-project/pull/104238
___
lldb-commits mailing list
ll

[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

[Dmitry Vasilyev via lldb-commits]

@@ -393,125 +362,222 @@ int main_platform(int argc, char *argv[]) {
   lldb_private::Args inferior_arguments;
   inferior_arguments.SetArguments(argc, const_cast(argv));
 
+  Socket::SocketProtocol protocol = Socket::ProtocolUnixDomain;
+
   if (fd != SharedSocket::kInvalidFD) {
 // Child process will handle the connection and exit.
+if (gdbserver_port)
+  protocol = Socket::ProtocolTcp;
+
 Log *log = GetLog(LLDBLog::Platform);
-if (!listen_host_port.empty()) {
-  LLDB_LOGF(log, "lldb-platform child: "
- "ambiguous parameters --listen and --child-platform-fd");
-  return socket_error;
-}
 
-NativeSocket socket;
-error = SharedSocket::GetNativeSocket(fd, socket);
+NativeSocket sockfd;
+error = SharedSocket::GetNativeSocket(fd, sockfd);
 if (error.Fail()) {
   LLDB_LOGF(log, "lldb-platform child: %s", error.AsCString());
   return socket_error;
 }
 
-GDBRemoteCommunicationServerPlatform platform(Socket::ProtocolTcp, "tcp");
-if (port_offset > 0)
-  platform.SetPortOffset(port_offset);
-platform.SetPortMap(std::move(gdbserver_portmap));
+GDBRemoteCommunicationServerPlatform platform(protocol, gdbserver_port);
+Socket *socket;
+if (protocol == Socket::ProtocolTcp)
+  socket = new TCPSocket(sockfd, /*should_close=*/true,
+ /*child_processes_inherit=*/false);
+else {
+#if LLDB_ENABLE_POSIX
+  socket = new DomainSocket(sockfd, /*should_close=*/true,
+/*child_processes_inherit=*/false);
+#else
+  LLDB_LOGF(log,
+"lldb-platform child: Unix domain sockets are not supported on 
"
+"this platform.");
+  return socket_error;
+#endif
+}
 platform.SetConnection(
-std::unique_ptr(new ConnectionFileDescriptor(
-new TCPSocket(socket, /*should_close=*/true,
-  /*child_processes_inherit=*/false;
+std::unique_ptr(new ConnectionFileDescriptor(socket)));
 client_handle(platform, inferior_arguments);
 return 0;
   }
 
-  const bool children_inherit_listen_socket = false;
-  // the test suite makes many connections in parallel, let's not miss any.
-  // The highest this should get reasonably is a function of the number
-  // of target CPUs. For now, let's just use 100.
-  const int backlog = 100;
+  if (gdbserver_port != 0 &&
+  (gdbserver_port < LOW_PORT || gdbserver_port > HIGH_PORT)) {
+WithColor::error() << llvm::formatv("Port number {0} is not in the "
+"valid user port range of {1} - {2}\n",
+gdbserver_port, LOW_PORT, HIGH_PORT);
+return 1;
+  }
 
-  std::unique_ptr acceptor_up(Acceptor::Create(
-  listen_host_port, children_inherit_listen_socket, error));
-  if (error.Fail()) {
-fprintf(stderr, "failed to create acceptor: %s", error.AsCString());
-exit(socket_error);
+  std::string hostname;
+  uint16_t platform_port = 0;
+
+  // Try to match socket name as URL - e.g., tcp://localhost:
+  if (std::optional uri = URI::Parse(listen_host_port)) {
+if (!Socket::FindProtocolByScheme(uri->scheme.str().c_str(), protocol)) {
+  fprintf(stderr, "Unknown protocol scheme \"%s\".",
+  uri->scheme.str().c_str());
+  return socket_error;
+}
+if (protocol == Socket::ProtocolTcp) {
+  hostname = uri->hostname;
+  if (uri->port) {
+platform_port = *(uri->port);
+  }
+} else
+  hostname = listen_host_port.substr(uri->scheme.size() + strlen("://"));
+  } else {
+// Try to match socket name as $host:port - e.g., localhost:
+llvm::Expected host_port =
+Socket::DecodeHostAndPort(listen_host_port);
+if (!llvm::errorToBool(host_port.takeError())) {
+  protocol = Socket::ProtocolTcp;
+  hostname = host_port->hostname;
+  platform_port = host_port->port;
+} else
+  hostname = listen_host_port;
   }
 
-  error = acceptor_up->Listen(backlog);
+  if (protocol == Socket::ProtocolTcp) {
+if (platform_port != 0 && platform_port == gdbserver_port) {
+  fprintf(stderr, "The same platform and gdb ports %u.", platform_port);
+  return socket_error;
+}
+  } else {
+if (gdbserver_port) {
+  fprintf(stderr,
+  "--gdbserver-port %u is redundant for non-tcp protocol %s.",
+  gdbserver_port, Socket::FindSchemeByProtocol(protocol));
+  return socket_error;
+}
+if (g_server) {
+  fprintf(stderr,
+  "Ambiguous parameters --server --listen %s.\n"
+  "The protocol must be tcp for the server mode.",
+  listen_host_port.c_str());
+  return socket_error;
+}
+  }
+
+  std::unique_ptr sock_platform =
+  Socket::Create(protocol, /*child_processes_inherit=*/false, error);
+  if (error.Fail()) {
+printf("Failed to create platform socket: %s\n", err

[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

[Dmitry Vasilyev via lldb-commits]

@@ -393,125 +362,222 @@ int main_platform(int argc, char *argv[]) {
   lldb_private::Args inferior_arguments;
   inferior_arguments.SetArguments(argc, const_cast(argv));
 
+  Socket::SocketProtocol protocol = Socket::ProtocolUnixDomain;
+
   if (fd != SharedSocket::kInvalidFD) {
 // Child process will handle the connection and exit.
+if (gdbserver_port)
+  protocol = Socket::ProtocolTcp;
+
 Log *log = GetLog(LLDBLog::Platform);
-if (!listen_host_port.empty()) {
-  LLDB_LOGF(log, "lldb-platform child: "
- "ambiguous parameters --listen and --child-platform-fd");
-  return socket_error;
-}
 
-NativeSocket socket;
-error = SharedSocket::GetNativeSocket(fd, socket);
+NativeSocket sockfd;
+error = SharedSocket::GetNativeSocket(fd, sockfd);
 if (error.Fail()) {
   LLDB_LOGF(log, "lldb-platform child: %s", error.AsCString());
   return socket_error;
 }
 
-GDBRemoteCommunicationServerPlatform platform(Socket::ProtocolTcp, "tcp");
-if (port_offset > 0)
-  platform.SetPortOffset(port_offset);
-platform.SetPortMap(std::move(gdbserver_portmap));
+GDBRemoteCommunicationServerPlatform platform(protocol, gdbserver_port);
+Socket *socket;
+if (protocol == Socket::ProtocolTcp)
+  socket = new TCPSocket(sockfd, /*should_close=*/true,
+ /*child_processes_inherit=*/false);
+else {
+#if LLDB_ENABLE_POSIX
+  socket = new DomainSocket(sockfd, /*should_close=*/true,
+/*child_processes_inherit=*/false);
+#else
+  LLDB_LOGF(log,
+"lldb-platform child: Unix domain sockets are not supported on 
"
+"this platform.");
+  return socket_error;
+#endif
+}
 platform.SetConnection(
-std::unique_ptr(new ConnectionFileDescriptor(
-new TCPSocket(socket, /*should_close=*/true,
-  /*child_processes_inherit=*/false;
+std::unique_ptr(new ConnectionFileDescriptor(socket)));
 client_handle(platform, inferior_arguments);
 return 0;
   }
 
-  const bool children_inherit_listen_socket = false;
-  // the test suite makes many connections in parallel, let's not miss any.
-  // The highest this should get reasonably is a function of the number
-  // of target CPUs. For now, let's just use 100.
-  const int backlog = 100;
+  if (gdbserver_port != 0 &&
+  (gdbserver_port < LOW_PORT || gdbserver_port > HIGH_PORT)) {
+WithColor::error() << llvm::formatv("Port number {0} is not in the "
+"valid user port range of {1} - {2}\n",
+gdbserver_port, LOW_PORT, HIGH_PORT);
+return 1;
+  }
 
-  std::unique_ptr acceptor_up(Acceptor::Create(
-  listen_host_port, children_inherit_listen_socket, error));
-  if (error.Fail()) {
-fprintf(stderr, "failed to create acceptor: %s", error.AsCString());
-exit(socket_error);
+  std::string hostname;
+  uint16_t platform_port = 0;
+
+  // Try to match socket name as URL - e.g., tcp://localhost:
+  if (std::optional uri = URI::Parse(listen_host_port)) {
+if (!Socket::FindProtocolByScheme(uri->scheme.str().c_str(), protocol)) {
+  fprintf(stderr, "Unknown protocol scheme \"%s\".",
+  uri->scheme.str().c_str());
+  return socket_error;
+}
+if (protocol == Socket::ProtocolTcp) {
+  hostname = uri->hostname;
+  if (uri->port) {
+platform_port = *(uri->port);
+  }
+} else
+  hostname = listen_host_port.substr(uri->scheme.size() + strlen("://"));
+  } else {
+// Try to match socket name as $host:port - e.g., localhost:
+llvm::Expected host_port =
+Socket::DecodeHostAndPort(listen_host_port);
+if (!llvm::errorToBool(host_port.takeError())) {
+  protocol = Socket::ProtocolTcp;
+  hostname = host_port->hostname;
+  platform_port = host_port->port;
+} else
+  hostname = listen_host_port;
   }

slydiman wrote:

Done

https://github.com/llvm/llvm-project/pull/104238
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [libcxx] [lldb] [lldb][libc++] Hide all libc++ implementation details from stacktraces (PR #108870)

[Adrian Vogelsgesang via lldb-commits]

https://github.com/vogelsgesang updated 
https://github.com/llvm/llvm-project/pull/108870

>From 04daaac0eade25a439856bbb287e15860aba1dfd Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Tue, 27 Aug 2024 17:34:11 +
Subject: [PATCH 1/6] [lldb][libc++] Hide all libc++ implementation details
 from stacktraces

This commit changes the libc++ frame recognizer to hide implementation
details of libc++ more aggressively. The applied heuristic is rather
straightforward: We consider every function name starting with `__` as
an implementation detail.

This works pretty neatly for `std::invoke`, `std::function`,
`std::sort`, `std::map::emplace` and many others. Also, this should
align quite nicely with libc++'s general coding convention of using the
`__` for their implementation details, thereby keeping the future
maintenance effort low.

However, it is noteworthy, that this does not work 100% in all cases:
E.g., for `std::ranges::sort`, itself is not really a function call, but
an object with an overloaded `operator()`, which means that there is no
actual call `std::ranges::sort` in the call stack.
---
 libcxx/docs/UserDocumentation.rst | 26 ++
 .../CPlusPlus/CPPLanguageRuntime.cpp  | 27 ++
 .../cpp/libcxx-internals-recognizer/Makefile  |  5 ++
 .../TestLibcxxInternalsRecognizer.py  | 56 
 .../cpp/libcxx-internals-recognizer/main.cpp  | 86 +++
 5 files changed, 181 insertions(+), 19 deletions(-)
 create mode 100644 lldb/test/API/lang/cpp/libcxx-internals-recognizer/Makefile
 create mode 100644 
lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
 create mode 100644 lldb/test/API/lang/cpp/libcxx-internals-recognizer/main.cpp

diff --git a/libcxx/docs/UserDocumentation.rst 
b/libcxx/docs/UserDocumentation.rst
index 6659fa54f49df5..8999b4f23e91d2 100644
--- a/libcxx/docs/UserDocumentation.rst
+++ b/libcxx/docs/UserDocumentation.rst
@@ -346,6 +346,32 @@ Third-party Integrations
 
 Libc++ provides integration with a few third-party tools.
 
+Debugging libc++ internals in LLDB
+--
+
+LLDB hides the implementation details of libc++ by default.
+
+E.g., when setting a breakpoint in a comparator passed to ``std::sort``, the
+backtrace will read as
+
+.. code-block::
+
+  (lldb) thread backtrace
+  * thread #1, name = 'a.out', stop reason = breakpoint 3.1
+* frame #0: 0x520e a.out`my_comparator(a=1, b=8) at 
test-std-sort.cpp:6:3
+  frame #7: 0x5615 a.out`void 
std::__1::sort[abi:ne20], bool (*)(int, 
int)>(__first=(item = 8), __last=(item = 0), __comp=(a.out`my_less(int, int) at 
test-std-sort.cpp:5)) at sort.h:1003:3
+  frame #8: 0x531a a.out`main at test-std-sort.cpp:24:3
+
+Note how the caller of ``my_comparator`` is shown as ``std::sort``. Looking at
+the frame numbers, we can see that frames #1 until #6 were hidden. Those frames
+represent internal implementation details such as ``__sort4`` and similar
+utility functions.
+
+To also show those implementation details, use ``thread backtrace -u``.
+Alternatively, to disable those compact backtraces for good, use
+``frame recognizer list`` and ``frame recognizer delete`` to delete the libc++
+frame recognizer.
+
 GDB Pretty printers for libc++
 --
 
diff --git 
a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp 
b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
index faa05e8f834ea1..d0e84bdeb94f01 100644
--- a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
+++ b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
@@ -45,7 +45,7 @@ char CPPLanguageRuntime::ID = 0;
 /// A frame recognizer that is installed to hide libc++ implementation
 /// details from the backtrace.
 class LibCXXFrameRecognizer : public StackFrameRecognizer {
-  std::array m_hidden_regex;
+  std::array m_hidden_regex;
   RecognizedStackFrameSP m_hidden_frame;
 
   struct LibCXXHiddenFrame : public RecognizedStackFrame {
@@ -55,28 +55,17 @@ class LibCXXFrameRecognizer : public StackFrameRecognizer {
 public:
   LibCXXFrameRecognizer()
   : m_hidden_regex{
-// internal implementation details of std::function
+// internal implementation details in the `std::` namespace
 //std::__1::__function::__alloc_func, void ()>::operator()[abi:ne20]
 //std::__1::__function::__func, void ()>::operator()
 //std::__1::__function::__value_func::operator()[abi:ne20]() const
-RegularExpression{""
-  R"(^std::__[^:]*::)" // Namespace.
-  R"(__function::.*::operator\(\))"},
-// internal implementation details of std::function in ABI v2
 //std::__2::__function::__policy_invoker::__call_impl[abi:ne20]>
-RegularExpression{""
-  R"(^std::__[^:]*::)" // Namespace.
-

[Lldb-commits] [libcxx] [lldb] [lldb][libc++] Hide all libc++ implementation details from stacktraces (PR #108870)

[Adrian Vogelsgesang via lldb-commits]

@@ -90,9 +79,26 @@ class LibCXXFrameRecognizer : public StackFrameRecognizer {
 if (!sc.function)
   return {};
 
+// Check if we have a regex match
+bool matches_regex = false;
 for (RegularExpression &r : m_hidden_regex)
-  if (r.Execute(sc.function->GetNameNoArguments()))
+  if (r.Execute(sc.function->GetNameNoArguments())) {
+matches_regex = true;
+break;
+  }
+
+if (matches_regex) {

vogelsgesang wrote:

purely stylistic. I find the code easier to read if every section takes care of 
a single thing.

In this case, I find it more readable if we have two separate code blocks:
1. first the code block that check if we match the regular expression
2. then a separate code block which checks for the parent frame

But this is clearly a subjective argument. If you want me to write this in some 
other way, please let me know 🙂 

https://github.com/llvm/llvm-project/pull/108870
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb/Interpreter] Propagate `script` output back to command return object (PR #109440)

[Pavel Labath via lldb-commits]

@@ -116,19 +118,50 @@ def run_python_interpreter(local_dict):
 print("Script exited with code %s" % e.code)
 
 
+class LLDBInteractiveConsole(code.InteractiveConsole):
+def __init__(self, locals=None):
+super().__init__(locals)
+self.result_output = None
+
+### Implementation detail:
+### 
https://docs.python.org/3/library/code.html#code.InteractiveInterpreter.runsource
+def runsource(self, source, filename="", symbol="single"):
+# Redirect stdout to capture print statements
+old_stdout = sys.stdout
+sys.stdout = result_output = StringIO()

labath wrote:

Apparently, there's even a [standard 
utility](https://docs.python.org/3/library/contextlib.html#contextlib.redirect_stdout)
 to do this, but it comes with a big warning (which I fully agree with):

```
Note that the global side effect on 
[sys.stdout](https://docs.python.org/3/library/sys.html#sys.stdout) means that 
this context manager is not suitable for use in library code and most threaded 
applications.
```

We tick both of those boxes. Is this redirection really necessary? Does 
anything prevent two instances of this function from running in parallel (e.g. 
on two debugger objects). If not, we're just setting ourself for a nasty race 
where the stdout just suddenly goes dead (because it's been permanently 
redirected to StringIO).  (Note that even if we can prevent races between in 
our own code, we can't prevent racing with anyone else attempting to do the 
same thing, nor we can stop inadvertently  capturing the output of other 
threads).

Capturing the result of the command makes sense to me, but capturing stdout, 
seems like its going too far. Maybe we could provide the StringIO object to the 
executed code as some sort of an argument, so that if the user really wants 
print there it can do something like `print(..., file=cmd_output)` ?

https://github.com/llvm/llvm-project/pull/109440
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-dap] Simplify `readMemory` (PR #109485)

[Pavel Labath via lldb-commits]

https://github.com/labath approved this pull request.

Thanks for doing this. I'll respond to your 
[https://github.com/llvm/llvm-project/pull/104317#issuecomment-2364684837] for 
the other thread here:

> > The method I'd recommend is to call ReadMemory

> I assume I should prefer Target::ReadMemory over Process::readMemory, right?

That would not be a correct assumption. However, I'm also not saying you should 
*not* use `Target::ReadMemory`. :P

The way I understand it, the main difference between the two functions is that 
the `Target` function also works before starting a process, and it may returned 
cached data from disk for running processes (which means it will be faster, but 
potentially return incorrect data).

You probably don't care about the first point. You may care about the second 
one, but I don't know how you should come to a decision there. If I was doing 
this, I'd use `SBProcess` because it's more convenient (it takes an integer 
instead of SBAddress), and matches what you've been doing already. However, I'm 
leaving that up to you..

https://github.com/llvm/llvm-project/pull/109485
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-dap] Simplify `readMemory` (PR #109485)

[Pavel Labath via lldb-commits]

@@ -93,20 +93,19 @@ def test_readMemory(self):
 
 # We can read the complete string
 mem = self.dap_server.request_readMemory(memref, 0, 5)["body"]
-self.assertEqual(mem["unreadableBytes"], 0)
 self.assertEqual(b64decode(mem["data"]), b"dead\0")
 
 # Use an offset
 mem = self.dap_server.request_readMemory(memref, 2, 3)["body"]
 self.assertEqual(b64decode(mem["data"]), b"ad\0")
 
 # Reads of size 0 are successful
-# VS-Code sends those in order to check if a `memoryReference` can 
actually be dereferenced.
+# VS Code sends those in order to check if a `memoryReference` can 
actually be dereferenced.
 mem = self.dap_server.request_readMemory(memref, 0, 0)
 self.assertEqual(mem["success"], True)
 self.assertEqual(mem["body"]["data"], "")
 
 # Reads at offset 0x0 fail
 mem = self.dap_server.request_readMemory("0x0", 0, 6)
 self.assertEqual(mem["success"], False)
-self.assertEqual(mem["message"], "Memory region is not readable")
+self.assertEqual(mem["message"], "memory read failed for 0x0")

labath wrote:

I suspect the error message will be different on windows. I'd probably just 
delete this check (and that's what I did in my PR).

https://github.com/llvm/llvm-project/pull/109485
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [clang-tools-extra] [lldb] [llvm] [SystemZ][z/OS] Propagate IsText parameter to open text files as text (PR #107906)

[Abhina Sree via lldb-commits]

abhina-sree wrote:

> OpenFlags |= sys::fs::OF_Text;

Thanks, I've made your suggested change and I opened a new PR here 
https://github.com/llvm/llvm-project/pull/109664. A short explanation for why 
distinguishing text and binary files on z/OS is important is because the native 
encoding is not UTF-8, so we need to know whether the file is text in order to 
convert to a UTF-8 encoding so that it is readable. 

https://github.com/llvm/llvm-project/pull/107906
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [libcxx] [lldb] [lldb][libc++] Hide all libc++ implementation details from stacktraces (PR #108870)

[Michael Buch via lldb-commits]

@@ -90,9 +79,26 @@ class LibCXXFrameRecognizer : public StackFrameRecognizer {
 if (!sc.function)
   return {};
 
+// Check if we have a regex match
+bool matches_regex = false;
 for (RegularExpression &r : m_hidden_regex)
-  if (r.Execute(sc.function->GetNameNoArguments()))
+  if (r.Execute(sc.function->GetNameNoArguments())) {
+matches_regex = true;
+break;
+  }
+
+if (matches_regex) {

Michael137 wrote:

Why split this out of the loop above?

https://github.com/llvm/llvm-project/pull/108870
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [libcxx] [lldb] [lldb][libc++] Hide all libc++ implementation details from stacktraces (PR #108870)

[Michael Buch via lldb-commits]

@@ -90,9 +79,26 @@ class LibCXXFrameRecognizer : public StackFrameRecognizer {
 if (!sc.function)
   return {};
 
+// Check if we have a regex match
+bool matches_regex = false;
 for (RegularExpression &r : m_hidden_regex)
-  if (r.Execute(sc.function->GetNameNoArguments()))
+  if (r.Execute(sc.function->GetNameNoArguments())) {
+matches_regex = true;
+break;
+  }
+
+if (matches_regex) {
+  // Only hide this frame if the immediate caller is also within libc++.
+  lldb::StackFrameSP parent_frame =
+  frame_sp->GetThread()->GetStackFrameAtIndex(
+  frame_sp->GetFrameIndex() + 1);
+  const auto &parent_sc =
+  parent_frame->GetSymbolContext(lldb::eSymbolContextFunction);
+  if (parent_sc.function->GetNameNoArguments().GetStringRef().starts_with(

Michael137 wrote:

`parent_sc.function` may not exist.

https://github.com/llvm/llvm-project/pull/108870
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [libcxx] [lldb] [lldb][libc++] Hide all libc++ implementation details from stacktraces (PR #108870)

[Michael Buch via lldb-commits]

@@ -346,6 +346,31 @@ Third-party Integrations
 
 Libc++ provides integration with a few third-party tools.
 
+Debugging libc++ internals in LLDB
+--
+
+LLDB hides the implementation details of libc++ by default.
+
+E.g., when setting a breakpoint in a comparator passed to ``std::sort``, the
+backtrace will read as
+
+.. code-block::
+
+  (lldb) thread backtrace
+  * thread #1, name = 'a.out', stop reason = breakpoint 3.1
+* frame #0: 0x520e a.out`my_comparator(a=1, b=8) at 
test-std-sort.cpp:6:3
+  frame #7: 0x5615 a.out`void 
std::__1::sort[abi:ne20], bool (*)(int, 
int)>(__first=(item = 8), __last=(item = 0), __comp=(a.out`my_less(int, int) at 
test-std-sort.cpp:5)) at sort.h:1003:3
+  frame #8: 0x531a a.out`main at test-std-sort.cpp:24:3
+
+Note how the caller of ``my_comparator`` is shown as ``std::sort``. Looking at
+the frame numbers, we can see that frames #1 until #6 were hidden. Those frames
+represent internal implementation details such as ``__sort4`` and similar
+utility functions.
+
+To also show those implementation details, use ``thread backtrace -u``.
+Alternatively, to disable those compact backtraces, use ``frame recognizer 
list``
+and ``frame recognizer disable`` on the "libc++ frame recognizer".
+

Michael137 wrote:

While we're here, could we also mention 
`target.process.thread.step-avoid-regexp`? Which is an LLDB setting set to 
`^std` by default. This disables stepping into libc++ functions. Happy to also 
just do that in a separate PR.

https://github.com/llvm/llvm-project/pull/108870
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [libcxx] [lldb] [lldb][libc++] Hide all libc++ implementation details from stacktraces (PR #108870)

[Michael Buch via lldb-commits]

@@ -90,9 +79,26 @@ class LibCXXFrameRecognizer : public StackFrameRecognizer {
 if (!sc.function)
   return {};
 
+// Check if we have a regex match
+bool matches_regex = false;
 for (RegularExpression &r : m_hidden_regex)
-  if (r.Execute(sc.function->GetNameNoArguments()))
+  if (r.Execute(sc.function->GetNameNoArguments())) {
+matches_regex = true;
+break;
+  }
+
+if (matches_regex) {
+  // Only hide this frame if the immediate caller is also within libc++.
+  lldb::StackFrameSP parent_frame =

Michael137 wrote:

`parent_frame` -> `parent_frame_sp`.

Also, we need to check `parent_frame` and `GetThread()` for `nullptr` here

https://github.com/llvm/llvm-project/pull/108870
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [libcxx] [lldb] [lldb][libc++] Hide all libc++ implementation details from stacktraces (PR #108870)

[Michael Buch via lldb-commits]

@@ -90,9 +79,26 @@ class LibCXXFrameRecognizer : public StackFrameRecognizer {
 if (!sc.function)
   return {};
 
+// Check if we have a regex match
+bool matches_regex = false;
 for (RegularExpression &r : m_hidden_regex)

Michael137 wrote:

Add braces to the outer loop

https://github.com/llvm/llvm-project/pull/108870
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

[Michael Buch via lldb-commits]

@@ -0,0 +1,94 @@
+# Adding Programming Language Support
+
+LLDB has been architected to make it straightforward to add support for a
+programming language. Only a small enum in core LLDB needs to be modified to
+make LLDB aware of a new programming language. Everything else can be supplied
+in derived classes that need not even be present in the core LLDB repository.
+This makes it convenient for developers adding language support in downstream
+repositories since it practically eliminates the potential for merge conflicts.
+
+The basic steps are:
+* Add the language to the `LanguageType` enum.
+* Add a `TypeSystem` for the language.
+* Add expression evaluation support.
+
+Additionally, you may want to create a `Language` and `LanguageRuntime` plugin
+for your language, which enables support for advanced features like dynamic
+typing and data formatting.
+
+## Add the Language to the LanguageType enum
+
+The `LanguageType` enum
+(see 
[lldb-enumerations.h](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/lldb-enumerations.h))
+contains a list of every language known to LLDB. It is the one place where
+support for a language must live that will need to merge cleanly with upstream
+LLDB if you are developing your language support in a separate branch. When
+adding support for a language previously unknown to LLDB, start by adding an
+enumeration entry to `LanguageType`.
+
+## Add a TypeSystem for the Language
+
+Both 
[Module](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Core/Module.h)
+and 
[Target](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Target/Target.h)
+support the retrieval of a `TypeSystem` instance via 
`GetTypeSystemForLanguage()`.
+For `Module`, this method is directly on the `Module` instance. For `Target`,
+this is retrieved indirectly via the `TypeSystemMap` for the `Target` instance.
+
+The `TypeSystem` instance returned by the `Target` is expected to be capable of
+evaluating expressions, while the `TypeSystem` instance returned by the 
`Module`
+is not. If want to support expression evaluation for your language, you could
+consider one of the following approaches:
+* Implement a single `TypeSystem` class that supports evaluation when given an
+  optional `Target`, implementing all the expression evaluation methods on the
+  `TypeSystem`.
+* Create multiple `TypeSystem` classes, one for evaluation and one for static
+  `Module` usage.
+
+For clang and Swift, the latter approach was chosen. Primarily to make it
+clearer that evaluation with the static `Module`-returned `TypeSystem` 
instances
+make no sense, and have them error out on those calls. But either approach is
+fine.
+
+# Add Expression Evaluation Support
+
+Expression Evaluation support is enabled by implementing the relevant methods 
on
+a `TypeSystem`-derived class. Search for `Expression` in the
+[TypeSystem 
header](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Symbol/TypeSystem.h)
+to find the methods to implement.
+
+# Type Completion
+
+There are three levels of type completion, each requiring more type 
information:

Michael137 wrote:

Think it's fine if we keep it and adjust as needed later on

https://github.com/llvm/llvm-project/pull/109427
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

[Pavel Labath via lldb-commits]

@@ -150,12 +153,17 @@ static void 
client_handle(GDBRemoteCommunicationServerPlatform &platform,
   printf("Disconnected.\n");
 }
 
-static GDBRemoteCommunicationServerPlatform::PortMap gdbserver_portmap;
-static std::mutex gdbserver_portmap_mutex;
-
 static void spawn_process_reaped(lldb::pid_t pid, int signal, int status) {
-  std::lock_guard guard(gdbserver_portmap_mutex);
-  gdbserver_portmap.FreePortForProcess(pid);
+  if (g_single_pid != LLDB_INVALID_PROCESS_ID && g_single_pid == pid) {
+// If not running as a server and the platform connection is closed
+if (!g_terminate) {
+  g_terminate = true;

labath wrote:

I'm only talking about the first case in here, and there I think it should be 
possible to come up with a completely safe shutdown procedure (and it's going 
to be hard to convince me otherwise).

As for the second case, I think that even what you have right now (change to a 
global) is out of scope of this patch, and we should continue discussing that 
separately (but note I'll still be against the global).

https://github.com/llvm/llvm-project/pull/104238
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

[Pavel Labath via lldb-commits]

@@ -393,125 +362,222 @@ int main_platform(int argc, char *argv[]) {
   lldb_private::Args inferior_arguments;
   inferior_arguments.SetArguments(argc, const_cast(argv));
 
+  Socket::SocketProtocol protocol = Socket::ProtocolUnixDomain;
+
   if (fd != SharedSocket::kInvalidFD) {
 // Child process will handle the connection and exit.
+if (gdbserver_port)
+  protocol = Socket::ProtocolTcp;
+
 Log *log = GetLog(LLDBLog::Platform);
-if (!listen_host_port.empty()) {
-  LLDB_LOGF(log, "lldb-platform child: "
- "ambiguous parameters --listen and --child-platform-fd");
-  return socket_error;
-}
 
-NativeSocket socket;
-error = SharedSocket::GetNativeSocket(fd, socket);
+NativeSocket sockfd;
+error = SharedSocket::GetNativeSocket(fd, sockfd);
 if (error.Fail()) {
   LLDB_LOGF(log, "lldb-platform child: %s", error.AsCString());
   return socket_error;
 }
 
-GDBRemoteCommunicationServerPlatform platform(Socket::ProtocolTcp, "tcp");
-if (port_offset > 0)
-  platform.SetPortOffset(port_offset);
-platform.SetPortMap(std::move(gdbserver_portmap));
+GDBRemoteCommunicationServerPlatform platform(protocol, gdbserver_port);
+Socket *socket;
+if (protocol == Socket::ProtocolTcp)
+  socket = new TCPSocket(sockfd, /*should_close=*/true,
+ /*child_processes_inherit=*/false);
+else {
+#if LLDB_ENABLE_POSIX
+  socket = new DomainSocket(sockfd, /*should_close=*/true,
+/*child_processes_inherit=*/false);
+#else
+  LLDB_LOGF(log,
+"lldb-platform child: Unix domain sockets are not supported on 
"
+"this platform.");
+  return socket_error;
+#endif
+}
 platform.SetConnection(
-std::unique_ptr(new ConnectionFileDescriptor(
-new TCPSocket(socket, /*should_close=*/true,
-  /*child_processes_inherit=*/false;
+std::unique_ptr(new ConnectionFileDescriptor(socket)));
 client_handle(platform, inferior_arguments);
 return 0;
   }
 
-  const bool children_inherit_listen_socket = false;
-  // the test suite makes many connections in parallel, let's not miss any.
-  // The highest this should get reasonably is a function of the number
-  // of target CPUs. For now, let's just use 100.
-  const int backlog = 100;
+  if (gdbserver_port != 0 &&
+  (gdbserver_port < LOW_PORT || gdbserver_port > HIGH_PORT)) {
+WithColor::error() << llvm::formatv("Port number {0} is not in the "
+"valid user port range of {1} - {2}\n",
+gdbserver_port, LOW_PORT, HIGH_PORT);
+return 1;
+  }
 
-  std::unique_ptr acceptor_up(Acceptor::Create(
-  listen_host_port, children_inherit_listen_socket, error));
-  if (error.Fail()) {
-fprintf(stderr, "failed to create acceptor: %s", error.AsCString());
-exit(socket_error);
+  std::string hostname;
+  uint16_t platform_port = 0;
+
+  // Try to match socket name as URL - e.g., tcp://localhost:
+  if (std::optional uri = URI::Parse(listen_host_port)) {
+if (!Socket::FindProtocolByScheme(uri->scheme.str().c_str(), protocol)) {
+  fprintf(stderr, "Unknown protocol scheme \"%s\".",
+  uri->scheme.str().c_str());
+  return socket_error;
+}
+if (protocol == Socket::ProtocolTcp) {
+  hostname = uri->hostname;
+  if (uri->port) {
+platform_port = *(uri->port);
+  }
+} else
+  hostname = listen_host_port.substr(uri->scheme.size() + strlen("://"));
+  } else {
+// Try to match socket name as $host:port - e.g., localhost:
+llvm::Expected host_port =
+Socket::DecodeHostAndPort(listen_host_port);
+if (!llvm::errorToBool(host_port.takeError())) {
+  protocol = Socket::ProtocolTcp;
+  hostname = host_port->hostname;
+  platform_port = host_port->port;
+} else
+  hostname = listen_host_port;
   }
 
-  error = acceptor_up->Listen(backlog);
+  if (protocol == Socket::ProtocolTcp) {
+if (platform_port != 0 && platform_port == gdbserver_port) {
+  fprintf(stderr, "The same platform and gdb ports %u.", platform_port);
+  return socket_error;
+}
+  } else {
+if (gdbserver_port) {
+  fprintf(stderr,
+  "--gdbserver-port %u is redundant for non-tcp protocol %s.",
+  gdbserver_port, Socket::FindSchemeByProtocol(protocol));
+  return socket_error;
+}
+if (g_server) {
+  fprintf(stderr,
+  "Ambiguous parameters --server --listen %s.\n"
+  "The protocol must be tcp for the server mode.",
+  listen_host_port.c_str());
+  return socket_error;
+}
+  }
+
+  std::unique_ptr sock_platform =
+  Socket::Create(protocol, /*child_processes_inherit=*/false, error);
+  if (error.Fail()) {
+printf("Failed to create platform socket: %s\n", err

[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

[Dmitry Vasilyev via lldb-commits]

@@ -393,125 +362,222 @@ int main_platform(int argc, char *argv[]) {
   lldb_private::Args inferior_arguments;
   inferior_arguments.SetArguments(argc, const_cast(argv));
 
+  Socket::SocketProtocol protocol = Socket::ProtocolUnixDomain;
+
   if (fd != SharedSocket::kInvalidFD) {
 // Child process will handle the connection and exit.
+if (gdbserver_port)
+  protocol = Socket::ProtocolTcp;
+
 Log *log = GetLog(LLDBLog::Platform);
-if (!listen_host_port.empty()) {
-  LLDB_LOGF(log, "lldb-platform child: "
- "ambiguous parameters --listen and --child-platform-fd");
-  return socket_error;
-}
 
-NativeSocket socket;
-error = SharedSocket::GetNativeSocket(fd, socket);
+NativeSocket sockfd;
+error = SharedSocket::GetNativeSocket(fd, sockfd);
 if (error.Fail()) {
   LLDB_LOGF(log, "lldb-platform child: %s", error.AsCString());
   return socket_error;
 }
 
-GDBRemoteCommunicationServerPlatform platform(Socket::ProtocolTcp, "tcp");
-if (port_offset > 0)
-  platform.SetPortOffset(port_offset);
-platform.SetPortMap(std::move(gdbserver_portmap));
+GDBRemoteCommunicationServerPlatform platform(protocol, gdbserver_port);
+Socket *socket;
+if (protocol == Socket::ProtocolTcp)
+  socket = new TCPSocket(sockfd, /*should_close=*/true,
+ /*child_processes_inherit=*/false);
+else {
+#if LLDB_ENABLE_POSIX
+  socket = new DomainSocket(sockfd, /*should_close=*/true,
+/*child_processes_inherit=*/false);
+#else
+  LLDB_LOGF(log,
+"lldb-platform child: Unix domain sockets are not supported on 
"
+"this platform.");
+  return socket_error;
+#endif
+}
 platform.SetConnection(
-std::unique_ptr(new ConnectionFileDescriptor(
-new TCPSocket(socket, /*should_close=*/true,
-  /*child_processes_inherit=*/false;
+std::unique_ptr(new ConnectionFileDescriptor(socket)));
 client_handle(platform, inferior_arguments);
 return 0;
   }
 
-  const bool children_inherit_listen_socket = false;
-  // the test suite makes many connections in parallel, let's not miss any.
-  // The highest this should get reasonably is a function of the number
-  // of target CPUs. For now, let's just use 100.
-  const int backlog = 100;
+  if (gdbserver_port != 0 &&
+  (gdbserver_port < LOW_PORT || gdbserver_port > HIGH_PORT)) {
+WithColor::error() << llvm::formatv("Port number {0} is not in the "
+"valid user port range of {1} - {2}\n",
+gdbserver_port, LOW_PORT, HIGH_PORT);
+return 1;
+  }
 
-  std::unique_ptr acceptor_up(Acceptor::Create(
-  listen_host_port, children_inherit_listen_socket, error));
-  if (error.Fail()) {
-fprintf(stderr, "failed to create acceptor: %s", error.AsCString());
-exit(socket_error);
+  std::string hostname;
+  uint16_t platform_port = 0;
+
+  // Try to match socket name as URL - e.g., tcp://localhost:
+  if (std::optional uri = URI::Parse(listen_host_port)) {
+if (!Socket::FindProtocolByScheme(uri->scheme.str().c_str(), protocol)) {
+  fprintf(stderr, "Unknown protocol scheme \"%s\".",
+  uri->scheme.str().c_str());
+  return socket_error;
+}
+if (protocol == Socket::ProtocolTcp) {
+  hostname = uri->hostname;
+  if (uri->port) {
+platform_port = *(uri->port);
+  }
+} else
+  hostname = listen_host_port.substr(uri->scheme.size() + strlen("://"));
+  } else {
+// Try to match socket name as $host:port - e.g., localhost:
+llvm::Expected host_port =
+Socket::DecodeHostAndPort(listen_host_port);
+if (!llvm::errorToBool(host_port.takeError())) {
+  protocol = Socket::ProtocolTcp;
+  hostname = host_port->hostname;
+  platform_port = host_port->port;
+} else
+  hostname = listen_host_port;
   }
 
-  error = acceptor_up->Listen(backlog);
+  if (protocol == Socket::ProtocolTcp) {
+if (platform_port != 0 && platform_port == gdbserver_port) {
+  fprintf(stderr, "The same platform and gdb ports %u.", platform_port);
+  return socket_error;
+}
+  } else {
+if (gdbserver_port) {
+  fprintf(stderr,
+  "--gdbserver-port %u is redundant for non-tcp protocol %s.",
+  gdbserver_port, Socket::FindSchemeByProtocol(protocol));
+  return socket_error;
+}
+if (g_server) {
+  fprintf(stderr,
+  "Ambiguous parameters --server --listen %s.\n"
+  "The protocol must be tcp for the server mode.",
+  listen_host_port.c_str());
+  return socket_error;
+}
+  }
+
+  std::unique_ptr sock_platform =
+  Socket::Create(protocol, /*child_processes_inherit=*/false, error);
+  if (error.Fail()) {
+printf("Failed to create platform socket: %s\n", err

[Lldb-commits] [clang] [lldb] [llvm] [mlir] [APInt] Fix APInt constructions where value does not fit bitwidth (NFCI) (PR #80309)

[Nikita Popov via lldb-commits]

nikic wrote:

@dtcxzyw Thanks for pointing that out! I think truncation here is the 
semantically wrong thing to do. I added a check that we fit the bit width 
instead in 
https://github.com/llvm/llvm-project/commit/6f194a6dea4b4067336431e699ea3588417d4b96.

https://github.com/llvm/llvm-project/pull/80309
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Fix assert frame recognizer for Ubuntu 22.04 (PR #109594)

[Michael Buch via lldb-commits]

https://github.com/Michael137 approved this pull request.

> I did not add a testcase because it would require a specific glibc.

To test this you could probably build a `libc.so` as part of building the test. 
Then have a dummy `__pthread_kill_implementation` in it. But given we haven't 
done this for the other symbols, feel free to ignore

https://github.com/llvm/llvm-project/pull/109594
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][AArch64][Linux] Add Floating Point Mode Register (PR #106695)

[David Spickett via lldb-commits]

DavidSpickett wrote:

ping!

https://github.com/llvm/llvm-project/pull/106695
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][AArch64] Create Neon subregs when XML only includes SVE (PR #108365)

[David Spickett via lldb-commits]

DavidSpickett wrote:

ping!

https://github.com/llvm/llvm-project/pull/108365
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Improve type and namespace lookup using parent chain (PR #108907)

[Pavel Labath via lldb-commits]

@@ -374,25 +377,40 @@ void DebugNamesDWARFIndex::GetFullyQualifiedType(
   m_fallback.GetFullyQualifiedType(context, callback);
 }
 
+bool DebugNamesDWARFIndex::SameAsEntryATName(
+llvm::StringRef query_name, const DebugNames::Entry &entry) const {
+  auto maybe_dieoffset = entry.getDIEUnitOffset();
+  if (!maybe_dieoffset)
+return false;
+
+  // [Optimization] instead of parsing the entry from dwo file, we simply
+  // check if the query_name can point to an entry of the same DIE offset.
+  // This greatly reduced number of dwo file parsed and thus improved the
+  // performance.
+  for (const DebugNames::Entry &query_entry :
+   entry.getNameIndex()->equal_range(query_name)) {
+auto query_dieoffset = query_entry.getDIEUnitOffset();
+if (!query_dieoffset)
+  continue;
+
+if (*query_dieoffset == *maybe_dieoffset) {
+  return true;
+} else if (*query_dieoffset > *maybe_dieoffset) {
+  // The pool entries of the same name are sequentially cluttered together
+  // so if the query name from `query_name` is after the target entry, this
+  // is definitely not the correct one, we can stop searching.

labath wrote:

Okay, that explains a few things, but then I'm not sure what you want to 
achieve with this check. It sounds to me like this consecutiveness is already 
guaranteed by the parser (it keeps parsing until it reaches the end-of-list 
entry). Maybe you could provide an example of the kind of situation that you 
want to detect/rule out?

https://github.com/llvm/llvm-project/pull/108907
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][FreeBSD] Fix a typo in NativeProcessFreeBSD::MonitorSIGTRAP() (PR #109643)

[Kelvin Lee via lldb-commits]

https://github.com/kiyolee created 
https://github.com/llvm/llvm-project/pull/109643

Apparently a typo is causing compile error.

>From f6af406b5465c190885be2364b3f8d48a2162780 Mon Sep 17 00:00:00 2001
From: Kelvin Lee 
Date: Mon, 23 Sep 2024 19:43:20 +1000
Subject: [PATCH] [lldb][FreeBSD] Fix a typo in
 NativeProcessFreeBSD::MonitorSIGTRAP()

---
 lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp 
b/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
index 80b27571f43d55..bf552e19742c4a 100644
--- a/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
+++ b/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
@@ -324,7 +324,7 @@ void NativeProcessFreeBSD::MonitorSIGTRAP(lldb::pid_t pid) {
 auto thread_info =
 m_threads_stepping_with_breakpoint.find(thread->GetID());
 if (thread_info != m_threads_stepping_with_breakpoint.end() &&
-threads_info->second == regctx.GetPC()) {
+thread_info->second == regctx.GetPC()) {
   thread->SetStoppedByTrace();
   Status brkpt_error = RemoveBreakpoint(thread_info->second);
   if (brkpt_error.Fail())

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

[Lldb-commits] [lldb] [lldb][FreeBSD] Fix a typo in NativeProcessFreeBSD::MonitorSIGTRAP() (PR #109643)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Kelvin Lee (kiyolee)


Changes

Apparently a typo is causing compile error.

---
Full diff: https://github.com/llvm/llvm-project/pull/109643.diff


1 Files Affected:

- (modified) lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp 
(+1-1) 


``diff
diff --git a/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp 
b/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
index 80b27571f43d55..bf552e19742c4a 100644
--- a/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
+++ b/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
@@ -324,7 +324,7 @@ void NativeProcessFreeBSD::MonitorSIGTRAP(lldb::pid_t pid) {
 auto thread_info =
 m_threads_stepping_with_breakpoint.find(thread->GetID());
 if (thread_info != m_threads_stepping_with_breakpoint.end() &&
-threads_info->second == regctx.GetPC()) {
+thread_info->second == regctx.GetPC()) {
   thread->SetStoppedByTrace();
   Status brkpt_error = RemoveBreakpoint(thread_info->second);
   if (brkpt_error.Fail())

``




https://github.com/llvm/llvm-project/pull/109643
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][NFC] New names for the two RegisterLocation classes (PR #109611)

[Felipe de Azevedo Piovezan via lldb-commits]

https://github.com/felipepiovezan approved this pull request.

As someone who was just recently learning about these parts of the codebase, 
this renaming will definitely make things easier! Thanks for creating this 
patch!

https://github.com/llvm/llvm-project/pull/109611
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Improve type lookup using .debug_names parent chain (PR #108907)

[via lldb-commits]

https://github.com/jeffreytan81 edited 
https://github.com/llvm/llvm-project/pull/108907
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Improve type lookup using .debug_names parent chain (PR #108907)

[via lldb-commits]

@@ -402,6 +420,36 @@ bool DebugNamesDWARFIndex::SameParentChain(
   return true;
 }
 
+bool DebugNamesDWARFIndex::WithinParentChain(
+llvm::ArrayRef query_parent_names,
+llvm::ArrayRef parent_chain) const {
+  if (parent_chain.size() < query_parent_names.size())
+return false;
+
+  size_t query_idx = 0, chain_idx = 0;
+  while (query_idx < query_parent_names.size() &&
+ chain_idx < parent_chain.size()) {
+if (SameAsEntryATName(query_parent_names[query_idx],
+  parent_chain[chain_idx])) {
+  ++query_idx;
+  ++chain_idx;
+} else {
+  // Name does not match, try next parent_chain entry if the current entry
+  // is namespace because the current one can be an inline namespace.

jeffreytan81 wrote:

The design is made to perform as much filtering as possible in 
`DebugNamesDWARFIndex::GetTypesWithQuery()`, it does not have to be accurate, 
because it will eventually delegate to base class 
`DWARFIndex::ProcessTypeDieMatchQuery()` which performs accurate semantics as 
the original callsite. 

https://github.com/llvm/llvm-project/pull/108907
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Improve type lookup using .debug_names parent chain (PR #108907)

[via lldb-commits]

https://github.com/jeffreytan81 edited 
https://github.com/llvm/llvm-project/pull/108907
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Improve type lookup using .debug_names parent chain (PR #108907)

[via lldb-commits]

jeffreytan81 wrote:

This PR has been updated to only contain the type lookup using .debug_names 
parent chain. 
Later PRs will add namespace changes and `SameAsATName` algorithm change. 

https://github.com/llvm/llvm-project/pull/108907
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define custom completers to the parsed_cmd template. (PR #109062)

[Med Ismail Bennani via lldb-commits]

https://github.com/medismailben approved this pull request.

LGTM! Thanks for addressing my comments :) 

https://github.com/llvm/llvm-project/pull/109062
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-dap] Simplify `readMemory` (PR #109485)

[Adrian Vogelsgesang via lldb-commits]

https://github.com/vogelsgesang updated 
https://github.com/llvm/llvm-project/pull/109485

>From 48718649469aae62b2945e7de22cf7280316b757 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Fri, 20 Sep 2024 21:05:54 +
Subject: [PATCH 1/2] [lldb-dap] Simplify `readMemory`

The `readMemory` request used the `MemoryRegionInfo` so it could also
support short reads. Since #106532, this is no longer necessary.

We no longer set the `unreadableBytes` in the result. But this is
optional, anyway, and afaik the VS Code UI would not yet make good use
of `unreadableBytes`, anyway.
---
 .../tools/lldb-dap/memory/TestDAP_memory.py   |  5 +-
 lldb/tools/lldb-dap/lldb-dap.cpp  | 69 +--
 2 files changed, 21 insertions(+), 53 deletions(-)

diff --git a/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py 
b/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
index 1082541aebcf7c..9c4bb794dccb61 100644
--- a/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
+++ b/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
@@ -93,7 +93,6 @@ def test_readMemory(self):
 
 # We can read the complete string
 mem = self.dap_server.request_readMemory(memref, 0, 5)["body"]
-self.assertEqual(mem["unreadableBytes"], 0)
 self.assertEqual(b64decode(mem["data"]), b"dead\0")
 
 # Use an offset
@@ -101,7 +100,7 @@ def test_readMemory(self):
 self.assertEqual(b64decode(mem["data"]), b"ad\0")
 
 # Reads of size 0 are successful
-# VS-Code sends those in order to check if a `memoryReference` can 
actually be dereferenced.
+# VS Code sends those in order to check if a `memoryReference` can 
actually be dereferenced.
 mem = self.dap_server.request_readMemory(memref, 0, 0)
 self.assertEqual(mem["success"], True)
 self.assertEqual(mem["body"]["data"], "")
@@ -109,4 +108,4 @@ def test_readMemory(self):
 # Reads at offset 0x0 fail
 mem = self.dap_server.request_readMemory("0x0", 0, 6)
 self.assertEqual(mem["success"], False)
-self.assertEqual(mem["message"], "Memory region is not readable")
+self.assertEqual(mem["message"], "memory read failed for 0x0")
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index 2fb86f675b4516..1ee04f0089179e 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -4405,14 +4405,6 @@ void request_readMemory(const llvm::json::Object 
&request) {
   FillResponse(request, response);
   auto *arguments = request.getObject("arguments");
 
-  lldb::SBProcess process = g_dap.target.GetProcess();
-  if (!process.IsValid()) {
-response["success"] = false;
-response["message"] = "No process running";
-g_dap.SendJSON(llvm::json::Value(std::move(response)));
-return;
-  }
-
   llvm::StringRef memoryReference = GetString(arguments, "memoryReference");
   auto addr_opt = DecodeMemoryReference(memoryReference);
   if (!addr_opt.has_value()) {
@@ -4422,57 +4414,34 @@ void request_readMemory(const llvm::json::Object 
&request) {
 g_dap.SendJSON(llvm::json::Value(std::move(response)));
 return;
   }
-  lldb::addr_t addr = *addr_opt;
+  lldb::addr_t addr_int = *addr_opt;
+  addr_int += GetSigned(arguments, "offset", 0);
+  const uint64_t count_requested = GetUnsigned(arguments, "count", 0);
 
-  addr += GetSigned(arguments, "offset", 0);
-  const uint64_t requested_count = GetUnsigned(arguments, "count", 0);
-  lldb::SBMemoryRegionInfo region_info;
-  lldb::SBError memreg_error = process.GetMemoryRegionInfo(addr, region_info);
-  if (memreg_error.Fail()) {
-response["success"] = false;
-EmplaceSafeString(response, "message",
-  "Unable to find memory region: " +
-  std::string(memreg_error.GetCString()));
-g_dap.SendJSON(llvm::json::Value(std::move(response)));
-return;
-  }
-  if (!region_info.IsReadable()) {
+  lldb::SBAddress addr =
+  g_dap.target.ResolveLoadAddress(addr_int);
+
+  // We also need support reading 0 bytes
+  // VS Code sends those requests to check if a `memoryReference`
+  // can be dereferenced.
+  const uint64_t count_read = std::max(count_requested, 1);
+  std::vector buf;
+  buf.resize(count_read);
+  lldb::SBError error;
+  size_t count_result =
+  g_dap.target.ReadMemory(addr, buf.data(), count_read, error);
+  if (error.Fail()) {
 response["success"] = false;
-response.try_emplace("message", "Memory region is not readable");
+EmplaceSafeString(response, "message", error.GetCString());
 g_dap.SendJSON(llvm::json::Value(std::move(response)));
 return;
   }
-  const uint64_t available_count =
-  std::min(requested_count, region_info.GetRegionEnd() - addr);
-  const uint64_t unavailable_count = requested_count - available_count;
-
-  std::vector buf;
-  buf.resize(available_count);
-  if (available_count > 0) {
-lldb::SBError memread_error;
-uint64_t bytes_r

[Lldb-commits] [libcxx] [lldb] [lldb][libc++] Hide all libc++ implementation details from stacktraces (PR #108870)

[Adrian Vogelsgesang via lldb-commits]

https://github.com/vogelsgesang updated 
https://github.com/llvm/llvm-project/pull/108870

>From 04daaac0eade25a439856bbb287e15860aba1dfd Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Tue, 27 Aug 2024 17:34:11 +
Subject: [PATCH 1/7] [lldb][libc++] Hide all libc++ implementation details
 from stacktraces

This commit changes the libc++ frame recognizer to hide implementation
details of libc++ more aggressively. The applied heuristic is rather
straightforward: We consider every function name starting with `__` as
an implementation detail.

This works pretty neatly for `std::invoke`, `std::function`,
`std::sort`, `std::map::emplace` and many others. Also, this should
align quite nicely with libc++'s general coding convention of using the
`__` for their implementation details, thereby keeping the future
maintenance effort low.

However, it is noteworthy, that this does not work 100% in all cases:
E.g., for `std::ranges::sort`, itself is not really a function call, but
an object with an overloaded `operator()`, which means that there is no
actual call `std::ranges::sort` in the call stack.
---
 libcxx/docs/UserDocumentation.rst | 26 ++
 .../CPlusPlus/CPPLanguageRuntime.cpp  | 27 ++
 .../cpp/libcxx-internals-recognizer/Makefile  |  5 ++
 .../TestLibcxxInternalsRecognizer.py  | 56 
 .../cpp/libcxx-internals-recognizer/main.cpp  | 86 +++
 5 files changed, 181 insertions(+), 19 deletions(-)
 create mode 100644 lldb/test/API/lang/cpp/libcxx-internals-recognizer/Makefile
 create mode 100644 
lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
 create mode 100644 lldb/test/API/lang/cpp/libcxx-internals-recognizer/main.cpp

diff --git a/libcxx/docs/UserDocumentation.rst 
b/libcxx/docs/UserDocumentation.rst
index 6659fa54f49df5..8999b4f23e91d2 100644
--- a/libcxx/docs/UserDocumentation.rst
+++ b/libcxx/docs/UserDocumentation.rst
@@ -346,6 +346,32 @@ Third-party Integrations
 
 Libc++ provides integration with a few third-party tools.
 
+Debugging libc++ internals in LLDB
+--
+
+LLDB hides the implementation details of libc++ by default.
+
+E.g., when setting a breakpoint in a comparator passed to ``std::sort``, the
+backtrace will read as
+
+.. code-block::
+
+  (lldb) thread backtrace
+  * thread #1, name = 'a.out', stop reason = breakpoint 3.1
+* frame #0: 0x520e a.out`my_comparator(a=1, b=8) at 
test-std-sort.cpp:6:3
+  frame #7: 0x5615 a.out`void 
std::__1::sort[abi:ne20], bool (*)(int, 
int)>(__first=(item = 8), __last=(item = 0), __comp=(a.out`my_less(int, int) at 
test-std-sort.cpp:5)) at sort.h:1003:3
+  frame #8: 0x531a a.out`main at test-std-sort.cpp:24:3
+
+Note how the caller of ``my_comparator`` is shown as ``std::sort``. Looking at
+the frame numbers, we can see that frames #1 until #6 were hidden. Those frames
+represent internal implementation details such as ``__sort4`` and similar
+utility functions.
+
+To also show those implementation details, use ``thread backtrace -u``.
+Alternatively, to disable those compact backtraces for good, use
+``frame recognizer list`` and ``frame recognizer delete`` to delete the libc++
+frame recognizer.
+
 GDB Pretty printers for libc++
 --
 
diff --git 
a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp 
b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
index faa05e8f834ea1..d0e84bdeb94f01 100644
--- a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
+++ b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
@@ -45,7 +45,7 @@ char CPPLanguageRuntime::ID = 0;
 /// A frame recognizer that is installed to hide libc++ implementation
 /// details from the backtrace.
 class LibCXXFrameRecognizer : public StackFrameRecognizer {
-  std::array m_hidden_regex;
+  std::array m_hidden_regex;
   RecognizedStackFrameSP m_hidden_frame;
 
   struct LibCXXHiddenFrame : public RecognizedStackFrame {
@@ -55,28 +55,17 @@ class LibCXXFrameRecognizer : public StackFrameRecognizer {
 public:
   LibCXXFrameRecognizer()
   : m_hidden_regex{
-// internal implementation details of std::function
+// internal implementation details in the `std::` namespace
 //std::__1::__function::__alloc_func, void ()>::operator()[abi:ne20]
 //std::__1::__function::__func, void ()>::operator()
 //std::__1::__function::__value_func::operator()[abi:ne20]() const
-RegularExpression{""
-  R"(^std::__[^:]*::)" // Namespace.
-  R"(__function::.*::operator\(\))"},
-// internal implementation details of std::function in ABI v2
 //std::__2::__function::__policy_invoker::__call_impl[abi:ne20]>
-RegularExpression{""
-  R"(^std::__[^:]*::)" // Namespace.
-

[Lldb-commits] [lldb] [lldb-dap] Simplify `readMemory` (PR #109485)

[Adrian Vogelsgesang via lldb-commits]

https://github.com/vogelsgesang updated 
https://github.com/llvm/llvm-project/pull/109485

>From f461249eed7bf26f87b156d071ad2a12ecd231ab Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Fri, 20 Sep 2024 21:05:54 +
Subject: [PATCH 1/3] [lldb-dap] Simplify `readMemory`

The `readMemory` request used the `MemoryRegionInfo` so it could also
support short reads. Since #106532, this is no longer necessary.

We no longer set the `unreadableBytes` in the result. But this is
optional, anyway, and afaik the VS Code UI would not yet make good use
of `unreadableBytes`, anyway.
---
 .../tools/lldb-dap/memory/TestDAP_memory.py   |  5 +-
 lldb/tools/lldb-dap/lldb-dap.cpp  | 69 +--
 2 files changed, 21 insertions(+), 53 deletions(-)

diff --git a/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py 
b/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
index 1082541aebcf7c..9c4bb794dccb61 100644
--- a/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
+++ b/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
@@ -93,7 +93,6 @@ def test_readMemory(self):
 
 # We can read the complete string
 mem = self.dap_server.request_readMemory(memref, 0, 5)["body"]
-self.assertEqual(mem["unreadableBytes"], 0)
 self.assertEqual(b64decode(mem["data"]), b"dead\0")
 
 # Use an offset
@@ -101,7 +100,7 @@ def test_readMemory(self):
 self.assertEqual(b64decode(mem["data"]), b"ad\0")
 
 # Reads of size 0 are successful
-# VS-Code sends those in order to check if a `memoryReference` can 
actually be dereferenced.
+# VS Code sends those in order to check if a `memoryReference` can 
actually be dereferenced.
 mem = self.dap_server.request_readMemory(memref, 0, 0)
 self.assertEqual(mem["success"], True)
 self.assertEqual(mem["body"]["data"], "")
@@ -109,4 +108,4 @@ def test_readMemory(self):
 # Reads at offset 0x0 fail
 mem = self.dap_server.request_readMemory("0x0", 0, 6)
 self.assertEqual(mem["success"], False)
-self.assertEqual(mem["message"], "Memory region is not readable")
+self.assertEqual(mem["message"], "memory read failed for 0x0")
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index c7653fed2def4e..24d250968ddd09 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -4422,14 +4422,6 @@ void request_readMemory(const llvm::json::Object 
&request) {
   FillResponse(request, response);
   auto *arguments = request.getObject("arguments");
 
-  lldb::SBProcess process = g_dap.target.GetProcess();
-  if (!process.IsValid()) {
-response["success"] = false;
-response["message"] = "No process running";
-g_dap.SendJSON(llvm::json::Value(std::move(response)));
-return;
-  }
-
   llvm::StringRef memoryReference = GetString(arguments, "memoryReference");
   auto addr_opt = DecodeMemoryReference(memoryReference);
   if (!addr_opt.has_value()) {
@@ -4439,57 +4431,34 @@ void request_readMemory(const llvm::json::Object 
&request) {
 g_dap.SendJSON(llvm::json::Value(std::move(response)));
 return;
   }
-  lldb::addr_t addr = *addr_opt;
+  lldb::addr_t addr_int = *addr_opt;
+  addr_int += GetSigned(arguments, "offset", 0);
+  const uint64_t count_requested = GetUnsigned(arguments, "count", 0);
 
-  addr += GetSigned(arguments, "offset", 0);
-  const uint64_t requested_count = GetUnsigned(arguments, "count", 0);
-  lldb::SBMemoryRegionInfo region_info;
-  lldb::SBError memreg_error = process.GetMemoryRegionInfo(addr, region_info);
-  if (memreg_error.Fail()) {
-response["success"] = false;
-EmplaceSafeString(response, "message",
-  "Unable to find memory region: " +
-  std::string(memreg_error.GetCString()));
-g_dap.SendJSON(llvm::json::Value(std::move(response)));
-return;
-  }
-  if (!region_info.IsReadable()) {
+  lldb::SBAddress addr =
+  g_dap.target.ResolveLoadAddress(addr_int);
+
+  // We also need support reading 0 bytes
+  // VS Code sends those requests to check if a `memoryReference`
+  // can be dereferenced.
+  const uint64_t count_read = std::max(count_requested, 1);
+  std::vector buf;
+  buf.resize(count_read);
+  lldb::SBError error;
+  size_t count_result =
+  g_dap.target.ReadMemory(addr, buf.data(), count_read, error);
+  if (error.Fail()) {
 response["success"] = false;
-response.try_emplace("message", "Memory region is not readable");
+EmplaceSafeString(response, "message", error.GetCString());
 g_dap.SendJSON(llvm::json::Value(std::move(response)));
 return;
   }
-  const uint64_t available_count =
-  std::min(requested_count, region_info.GetRegionEnd() - addr);
-  const uint64_t unavailable_count = requested_count - available_count;
-
-  std::vector buf;
-  buf.resize(available_count);
-  if (available_count > 0) {
-lldb::SBError memread_error;
-uint64_t bytes_r

[Lldb-commits] [lldb] [lldb-dap] Simplify `readMemory` (PR #109485)

[Adrian Vogelsgesang via lldb-commits]

vogelsgesang wrote:

> [...] it may returned cached data from disk for running processes (which 
> means it will be faster, but potentially return incorrect data).

I think the 2nd point shouldn't be an issue because `SBTarget::ReadMemory` sets 
`force_live_memory` to true when calling `Target::ReadMemory`

> [...] but I don't know how you should come to a decision there

I think I found a good criterion: Do whatever the `memory read` command is 
doing. Because users would probably expect the UI view and the results from 
`memory read` to be in-sync. It turns out `memory read` is using 
`Target::ReadMemory`. So I would like to do the same here, except if you are 
aware of good reasons not to do so

https://github.com/llvm/llvm-project/pull/109485
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #99736)

[via lldb-commits]

@@ -3271,6 +3273,11 @@ Status Process::PrivateResume() {
   if (!GetModID().IsLastResumeForUserExpression())
 ResetExtendedCrashInfoDict();
 
+  if (m_last_run_direction != direction) {

jimingham wrote:

In the "resolved" discussion we talked about the fact that this will have to 
change if you ever support a mix of reverse and forward continuation.  Be good 
to leave a comment to that effect here so we won't have to refind where we need 
to fix this when the time arrives.

https://github.com/llvm/llvm-project/pull/99736
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #99736)

[via lldb-commits]

jimingham wrote:

> @clayborg @jimingham Can I please have some love? I don't want to keep 
> telling users "you should be using GDB" and I've done a significant amount of 
> work here.

Ack, sorry I'm bad at the formalities.  I was under the impression that most of 
the actual reviewing had been done and we were stalling on getting consensus on 
direction vrs. API's, but none of us clicked "Accept" so that's my bad.
I read through the patch again.  It all seems clear to me, I left a couple of 
comments about places I thought could use some docs, but none of them seem 
essential to me.

https://github.com/llvm/llvm-project/pull/99736
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #99736)

[via lldb-commits]

https://github.com/jimingham approved this pull request.

LGTM.  I went through and made a couple non-essential comment suggestions.  But 
this looks ready to go in to me.

https://github.com/llvm/llvm-project/pull/99736
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Don't invalid register context after setting thread pc's (PR #109499)

[via lldb-commits]

https://github.com/jimingham approved this pull request.

LGTM.  

Given InvalidateIfNeeded (which by name seems harmless) can have these 
undesirably effects (presumably only when you pass true for force) it might be 
nice to warn developers about this by adding an instructive comment to 
InvalidateIfNeeded?

But the content seems fine here.

https://github.com/llvm/llvm-project/pull/109499
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #99736)

[via lldb-commits]

@@ -3169,6 +3176,7 @@ void PruneThreadPlans();
// m_currently_handling_do_on_removals are true,
// Resume will only request a resume, using this
// flag to check.
+  lldb::RunDirection m_last_run_direction;

jimingham wrote:

This should have a doc string.  I've been trying not to make classes that 
default initialize some ivars in the class declaration and some in the 
constructors.  That just seems super confusing to me.  So I personally wouldn't 
initialize this one here, or I'd go fix all the ones we always initialize the 
same way in the constructors.  But that's a matter of taste.

https://github.com/llvm/llvm-project/pull/99736
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #99736)

[via lldb-commits]

@@ -142,6 +142,9 @@ class StopInfo : public 
std::enable_shared_from_this {
   static lldb::StopInfoSP
   CreateStopReasonProcessorTrace(Thread &thread, const char *description);
 
+  static lldb::StopInfoSP

jimingham wrote:

Do you somewhere make it obvious what a "history boundary" is? That seems a bit 
of a mysterious name to have no comment.

https://github.com/llvm/llvm-project/pull/99736
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #99736)

[via lldb-commits]

@@ -510,8 +510,9 @@ def start(self):
 self._thread.start()
 
 def stop(self):
-self._thread.join()
-self._thread = None
+if self._thread is not None:

jimingham wrote:

It's not obvious when you'd get a stop with no thread.  Why did you need this?

https://github.com/llvm/llvm-project/pull/99736
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #99736)

[via lldb-commits]

@@ -142,6 +142,9 @@ class StopInfo : public 
std::enable_shared_from_this {
   static lldb::StopInfoSP
   CreateStopReasonProcessorTrace(Thread &thread, const char *description);
 
+  static lldb::StopInfoSP

jimingham wrote:

Ah, okay, you do for eStopReasonHistoryBoundary, but that's fairly distant from 
this file. 

https://github.com/llvm/llvm-project/pull/99736
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 1fae131 - [lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)

[Adrian Prantl via lldb-commits]

Author: Adrian Prantl
Date: 2024-09-23T14:33:41-07:00
New Revision: 1fae1314f1ff58f3601640c0a2c48cee3a322e5d

URL: 
https://github.com/llvm/llvm-project/commit/1fae1314f1ff58f3601640c0a2c48cee3a322e5d
DIFF: 
https://github.com/llvm/llvm-project/commit/1fae1314f1ff58f3601640c0a2c48cee3a322e5d.diff

LOG: [lldb] Change the implementation of Status to store an llvm::Error (NFC) 
(#106774)

(based on a conversation I had with @labath yesterday in
https://github.com/llvm/llvm-project/pull/106442)

Most APIs that currently vend a Status would be better served by
returning llvm::Expected<> instead. If possibles APIs should be
refactored to avoid Status. The only legitimate long-term uses of Status
are objects that need to store an error for a long time (which should be
questioned as a design decision, too).

This patch makes the transition to llvm::Error easier by making the
places that cannot switch to llvm::Error explicit: They are marked with
a call to Status::clone(). Every other API can and should be refactored
to use llvm::Expected. In the end Status should only be used in very few
places.

Whenever an unchecked Error is dropped by Status it logs this to the
verbose API channel.

Implementation notes:

This patch introduces two new kinds of error_category as well as new
llvm::Error types. Here is the mapping of lldb::ErrorType to
llvm::Errors:
```
   (eErrorTypeInvalid)
   eErrorTypeGeneric  llvm::StringError
   eErrorTypePOSIXllvm::ECError
   eErrorTypeMachKernel   MachKernelError
   eErrorTypeExpression   llvm::ErrorList
   eErrorTypeWin32Win32Error
```

Relanding with built-in cloning support for llvm::ECError, and support
for initializing a Windows error with a NO_ERROR error code, and
modifying TestGDBRemotePlatformFile.py to support different renderings
of ENOSYS.

Added: 


Modified: 
lldb/include/lldb/Utility/Status.h
lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
lldb/source/Utility/Status.cpp
lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
lldb/unittests/Utility/StatusTest.cpp

Removed: 




diff  --git a/lldb/include/lldb/Utility/Status.h 
b/lldb/include/lldb/Utility/Status.h
index 795c830b965173..084ce4afb8cefd 100644
--- a/lldb/include/lldb/Utility/Status.h
+++ b/lldb/include/lldb/Utility/Status.h
@@ -28,6 +28,67 @@ namespace lldb_private {
 
 const char *ExpressionResultAsCString(lldb::ExpressionResults result);
 
+/// Going a bit against the spirit of llvm::Error,
+/// lldb_private::Status need to store errors long-term and sometimes
+/// copy them. This base class defines an interface for this
+/// operation.
+class CloneableError
+: public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  CloneableError() : ErrorInfo() {}
+  virtual std::unique_ptr Clone() const = 0;
+  static char ID;
+};
+
+/// Common base class for all error-code errors.
+class CloneableECError
+: public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  std::error_code convertToErrorCode() const override { return EC; }
+  void log(llvm::raw_ostream &OS) const override { OS << EC.message(); }
+  static char ID;
+
+protected:
+  CloneableECError() = delete;
+  CloneableECError(std::error_code ec) : ErrorInfo(), EC(ec) {}
+  std::error_code EC;
+};
+/// FIXME: Move these declarations closer to where they're used.
+class MachKernelError
+: public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  MachKernelError(std::error_code ec) : ErrorInfo(ec) {}
+  std::string message() const override;
+  std::unique_ptr Clone() const override;
+  static char ID;
+};
+
+class Win32Error : public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  Win32Error(std::error_code ec, const llvm::Twine &msg = {}) : ErrorInfo(ec) 
{}
+  std::string message() const override;
+  std::unique_ptr Clone() const override;
+  static char ID;
+};
+
+class ExpressionError
+: public llvm::ErrorInfo {
+public:
+  using llvm::ErrorInfo::ErrorInfo;
+  ExpressionError(std::error_code ec, std::string msg = {})
+  : ErrorInfo(ec), m_string(msg) {}
+  std::unique_ptr Clone() const override;
+  std::string message() const override { return m_string; }
+  static char ID;
+
+protected:
+  std::string m_string;
+};
+
 /// \class Status Status.h "lldb/Utility/Status.h" An error handling class.
 ///
 /// This class is designed to be able to hold any error code that can be
@@ -100,9 +161,7 @@ class Status {
   }
 
   static Status FromExpressionError(lldb::ExpressionResults result,
-std::string msg) {
-return Status(result, lldb::eErrorTypeExpression, msg);
-  }
+std::string msg);
 
   /// Set the current error to errno.
   ///
@@ -115,6 +174,7 @@ class Status {
   const Status &operator=(Status &&);
   /// Avoid using this in new code. 

[Lldb-commits] [lldb] [lldb] Don't invalid register context after setting thread pc's (PR #109499)

[Jason Molenda via lldb-commits]

https://github.com/jasonmolenda closed 
https://github.com/llvm/llvm-project/pull/109499
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 6e6d5ea - [lldb] Don't invalid register context after setting thread pc's (#109499)

[via lldb-commits]

Author: Jason Molenda
Date: 2024-09-23T12:13:48-07:00
New Revision: 6e6d5eae765939cc4074bdd606658e78c4a2a559

URL: 
https://github.com/llvm/llvm-project/commit/6e6d5eae765939cc4074bdd606658e78c4a2a559
DIFF: 
https://github.com/llvm/llvm-project/commit/6e6d5eae765939cc4074bdd606658e78c4a2a559.diff

LOG: [lldb] Don't invalid register context after setting thread pc's (#109499)

Some gdb remote serial protocol stubs will send the thread IDs and PCs
for all threads in a process in the stop-reply packet. lldb often needs
to know the pc values for all threads while at a private stop, and that
results in  read-register packets for  threads, and can be a big
performance problem when this is a hot code path.

GDBRemoteRegisterContext tracks the StopID of when its values were set,
and when the thread's StopID has incremented, it marks all values it has
as Invalid, and knows to refetch them.

We have a code path that resulted in setting the PCs for all the
threads, and then `ProcessGDBRemote::CalculateThreadStopInfo` *forcing*
an invalidation of all the register contexts, forcing us to re-read the
pc values for all threads except the one that stopped.

There are times when it is valid to force an invalidation of the
regsiter cache - for instance, if the layout of the registers has
changed because the processor state is different, or we've sent a
write-all-registers packet to the inferior and we want to make sure we
stay in sync with the inferior. But there was no reason for this method
to be forcing the register context to be invalid.

I added a test when running on Darwin systems, where debugserver always
sends the thread IDs and PCs, which turns on packet logging. The test
runs against an inferior which has 4 threads; it steps over a dlopen()
call, steps in to a user function with debug info, steps-over and
steps-in across source lines with multiple function calls, and then
examines the packet log and flags it as an error if lldb asked for the
pc value of any thread at any point in the debug session.

For this program and the operations we're doing, with debugserver that
provides thread IDs and PCs, we should never ask for the value of a pc
register.

rdar://136247381

Added: 
lldb/test/API/macosx/expedited-thread-pcs/Makefile
lldb/test/API/macosx/expedited-thread-pcs/TestExpeditedThreadPCs.py
lldb/test/API/macosx/expedited-thread-pcs/foo.c
lldb/test/API/macosx/expedited-thread-pcs/main.cpp

Modified: 
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp 
b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
index d5dfe79fd8862a..9e8c6046179631 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -1600,7 +1600,6 @@ bool 
ProcessGDBRemote::CalculateThreadStopInfo(ThreadGDBRemote *thread) {
 // If we have "jstopinfo" then we have stop descriptions for all threads
 // that have stop reasons, and if there is no entry for a thread, then it
 // has no stop reason.
-thread->GetRegisterContext()->InvalidateIfNeeded(true);
 if (!GetThreadStopInfoFromJSON(thread, m_jstopinfo_sp)) {
   // If a thread is stopped at a breakpoint site, set that as the stop
   // reason even if it hasn't executed the breakpoint instruction yet.

diff  --git a/lldb/test/API/macosx/expedited-thread-pcs/Makefile 
b/lldb/test/API/macosx/expedited-thread-pcs/Makefile
new file mode 100644
index 00..7799f06e770970
--- /dev/null
+++ b/lldb/test/API/macosx/expedited-thread-pcs/Makefile
@@ -0,0 +1,11 @@
+CXX_SOURCES := main.cpp
+
+.PHONY: build-libfoo
+all: build-libfoo a.out
+
+include Makefile.rules
+
+build-libfoo: foo.c
+   $(MAKE) -f $(MAKEFILE_RULES) \
+   DYLIB_C_SOURCES=foo.c DYLIB_NAME=foo DYLIB_ONLY=YES
+

diff  --git 
a/lldb/test/API/macosx/expedited-thread-pcs/TestExpeditedThreadPCs.py 
b/lldb/test/API/macosx/expedited-thread-pcs/TestExpeditedThreadPCs.py
new file mode 100644
index 00..0611907a34b0d6
--- /dev/null
+++ b/lldb/test/API/macosx/expedited-thread-pcs/TestExpeditedThreadPCs.py
@@ -0,0 +1,91 @@
+"""Test that the expedited thread pc values are not re-fetched by lldb."""
+
+import subprocess
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+file_index = 0
+
+
+class TestExpeditedThreadPCs(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+
+@skipUnlessDarwin
+def test_expedited_thread_pcs(self):
+TestBase.setUp(self)
+
+global file_index
+++file_index
+logfile = os.path.join(
+self.getBuildDir(),
+"packet-log-" + self.getArchitecture() + "-" + str(file_index) + 
".txt",
+)
+self.runCmd("log enable -f %s gdb-remote packets"

[Lldb-commits] [libcxx] [lldb] [lldb][libc++] Hide all libc++ implementation details from stacktraces (PR #108870)

[Adrian Vogelsgesang via lldb-commits]

vogelsgesang wrote:

@Michael137 thanks for the review! I updated the pull request accordingly

https://github.com/llvm/llvm-project/pull/108870
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [libcxx] [lldb] [lldb][libc++] Hide all libc++ implementation details from stacktraces (PR #108870)

[Adrian Vogelsgesang via lldb-commits]

https://github.com/vogelsgesang updated 
https://github.com/llvm/llvm-project/pull/108870

>From 04daaac0eade25a439856bbb287e15860aba1dfd Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Tue, 27 Aug 2024 17:34:11 +
Subject: [PATCH 1/6] [lldb][libc++] Hide all libc++ implementation details
 from stacktraces

This commit changes the libc++ frame recognizer to hide implementation
details of libc++ more aggressively. The applied heuristic is rather
straightforward: We consider every function name starting with `__` as
an implementation detail.

This works pretty neatly for `std::invoke`, `std::function`,
`std::sort`, `std::map::emplace` and many others. Also, this should
align quite nicely with libc++'s general coding convention of using the
`__` for their implementation details, thereby keeping the future
maintenance effort low.

However, it is noteworthy, that this does not work 100% in all cases:
E.g., for `std::ranges::sort`, itself is not really a function call, but
an object with an overloaded `operator()`, which means that there is no
actual call `std::ranges::sort` in the call stack.
---
 libcxx/docs/UserDocumentation.rst | 26 ++
 .../CPlusPlus/CPPLanguageRuntime.cpp  | 27 ++
 .../cpp/libcxx-internals-recognizer/Makefile  |  5 ++
 .../TestLibcxxInternalsRecognizer.py  | 56 
 .../cpp/libcxx-internals-recognizer/main.cpp  | 86 +++
 5 files changed, 181 insertions(+), 19 deletions(-)
 create mode 100644 lldb/test/API/lang/cpp/libcxx-internals-recognizer/Makefile
 create mode 100644 
lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
 create mode 100644 lldb/test/API/lang/cpp/libcxx-internals-recognizer/main.cpp

diff --git a/libcxx/docs/UserDocumentation.rst 
b/libcxx/docs/UserDocumentation.rst
index 6659fa54f49df5..8999b4f23e91d2 100644
--- a/libcxx/docs/UserDocumentation.rst
+++ b/libcxx/docs/UserDocumentation.rst
@@ -346,6 +346,32 @@ Third-party Integrations
 
 Libc++ provides integration with a few third-party tools.
 
+Debugging libc++ internals in LLDB
+--
+
+LLDB hides the implementation details of libc++ by default.
+
+E.g., when setting a breakpoint in a comparator passed to ``std::sort``, the
+backtrace will read as
+
+.. code-block::
+
+  (lldb) thread backtrace
+  * thread #1, name = 'a.out', stop reason = breakpoint 3.1
+* frame #0: 0x520e a.out`my_comparator(a=1, b=8) at 
test-std-sort.cpp:6:3
+  frame #7: 0x5615 a.out`void 
std::__1::sort[abi:ne20], bool (*)(int, 
int)>(__first=(item = 8), __last=(item = 0), __comp=(a.out`my_less(int, int) at 
test-std-sort.cpp:5)) at sort.h:1003:3
+  frame #8: 0x531a a.out`main at test-std-sort.cpp:24:3
+
+Note how the caller of ``my_comparator`` is shown as ``std::sort``. Looking at
+the frame numbers, we can see that frames #1 until #6 were hidden. Those frames
+represent internal implementation details such as ``__sort4`` and similar
+utility functions.
+
+To also show those implementation details, use ``thread backtrace -u``.
+Alternatively, to disable those compact backtraces for good, use
+``frame recognizer list`` and ``frame recognizer delete`` to delete the libc++
+frame recognizer.
+
 GDB Pretty printers for libc++
 --
 
diff --git 
a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp 
b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
index faa05e8f834ea1..d0e84bdeb94f01 100644
--- a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
+++ b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
@@ -45,7 +45,7 @@ char CPPLanguageRuntime::ID = 0;
 /// A frame recognizer that is installed to hide libc++ implementation
 /// details from the backtrace.
 class LibCXXFrameRecognizer : public StackFrameRecognizer {
-  std::array m_hidden_regex;
+  std::array m_hidden_regex;
   RecognizedStackFrameSP m_hidden_frame;
 
   struct LibCXXHiddenFrame : public RecognizedStackFrame {
@@ -55,28 +55,17 @@ class LibCXXFrameRecognizer : public StackFrameRecognizer {
 public:
   LibCXXFrameRecognizer()
   : m_hidden_regex{
-// internal implementation details of std::function
+// internal implementation details in the `std::` namespace
 //std::__1::__function::__alloc_func, void ()>::operator()[abi:ne20]
 //std::__1::__function::__func, void ()>::operator()
 //std::__1::__function::__value_func::operator()[abi:ne20]() const
-RegularExpression{""
-  R"(^std::__[^:]*::)" // Namespace.
-  R"(__function::.*::operator\(\))"},
-// internal implementation details of std::function in ABI v2
 //std::__2::__function::__policy_invoker::__call_impl[abi:ne20]>
-RegularExpression{""
-  R"(^std::__[^:]*::)" // Namespace.
-

[Lldb-commits] [libcxx] [lldb] [lldb][libc++] Hide all libc++ implementation details from stacktraces (PR #108870)

[Adrian Vogelsgesang via lldb-commits]

@@ -346,6 +346,31 @@ Third-party Integrations
 
 Libc++ provides integration with a few third-party tools.
 
+Debugging libc++ internals in LLDB
+--
+
+LLDB hides the implementation details of libc++ by default.
+
+E.g., when setting a breakpoint in a comparator passed to ``std::sort``, the
+backtrace will read as
+
+.. code-block::
+
+  (lldb) thread backtrace
+  * thread #1, name = 'a.out', stop reason = breakpoint 3.1
+* frame #0: 0x520e a.out`my_comparator(a=1, b=8) at 
test-std-sort.cpp:6:3
+  frame #7: 0x5615 a.out`void 
std::__1::sort[abi:ne20], bool (*)(int, 
int)>(__first=(item = 8), __last=(item = 0), __comp=(a.out`my_less(int, int) at 
test-std-sort.cpp:5)) at sort.h:1003:3
+  frame #8: 0x531a a.out`main at test-std-sort.cpp:24:3
+
+Note how the caller of ``my_comparator`` is shown as ``std::sort``. Looking at
+the frame numbers, we can see that frames #1 until #6 were hidden. Those frames
+represent internal implementation details such as ``__sort4`` and similar
+utility functions.
+
+To also show those implementation details, use ``thread backtrace -u``.
+Alternatively, to disable those compact backtraces, use ``frame recognizer 
list``
+and ``frame recognizer disable`` on the "libc++ frame recognizer".
+

vogelsgesang wrote:

I assume that this mechanism can be disabled via `settings set 
target.process.thread.step-avoid-regexp ""`? Or would that match *every* frame 
and break stepping completely?

https://github.com/llvm/llvm-project/pull/108870
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits