[Lldb-commits] [lldb] [lldb] Refactor TypeQuery::ContextMatches, take 2 (PR #101333)

https://github.com/labath updated https://github.com/llvm/llvm-project/pull/101333 >From e87b2b24cd673584aabd00eaf6ad8fc4c0c52c98 Mon Sep 17 00:00:00 2001 From: Pavel Labath Date: Tue, 16 Jul 2024 14:18:27 + Subject: [PATCH 1/2] [lldb] Refactor TypeQuery::ContextMatches, take 2 This is an

[Lldb-commits] [lldb] [lldb] Refactor TypeQuery::ContextMatches, take 2 (PR #101333)

labath wrote: @Michael137, I'd appreciate it if you could give this a spin. If https://github.com/swiftlang/llvm-project/blob/ee8bc8b8d30eb99807adbcd3c1f044e00af66cdd/lldb/source/Plugins/TypeSystem/Swift/TypeSystemSwiftTypeRef.cpp#L219-L225 is the only use of `AnyModule`, then it should be

[Lldb-commits] [lldb] [lldb] Refactor TypeQuery::ContextMatches, take 2 (PR #101333)

https://github.com/labath created https://github.com/llvm/llvm-project/pull/101333 This is an alternative, much simpler implementation of #99305. In this version I replace the AnyModule wildcard match with a special TypeQuery flag which achieves (mostly) the same thing. It is a preparatory

[Lldb-commits] [lldb] [lldb] Fixed lldb-server crash (TestLogHandler was not thread safe) (PR #101326)

https://github.com/labath approved this pull request. This makes sense, though it would probably be even better to just use the real StreamLogHandler class. I think all that's needed would be to add a new constructor to it. https://github.com/llvm/llvm-project/pull/101326

[Lldb-commits] [lldb] [lldb] Updated lldb-server to spawn the child process and share socket on Windows (PR #101283)

labath wrote: > @labath > > > For consistency, and to minimize the number of ifdefs, I believe windows > > and non-windows paths should use as similar approaches as possible. That > > means I think the end state should be that the posix path also uses a > > fork+exec approach. > > fork+exec

[Lldb-commits] [lldb] [lldb] Unify the way we get the Target in CommandObject (PR #101208)

https://github.com/labath approved this pull request. https://github.com/llvm/llvm-project/pull/101208 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #101237)

@@ -402,6 +413,29 @@ class ObjectFileELF : public lldb_private::ObjectFile { /// .gnu_debugdata section or \c nullptr if an error occured or if there's no /// section with that name. std::shared_ptr GetGnuDebugDataObjectFile(); + + /// Get the bytes that represent the

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #101237)

@@ -2550,6 +2550,21 @@ ModuleSP Process::ReadModuleFromMemory(const FileSpec _spec, } ModuleSP module_sp(new Module(file_spec, ArchSpec())); if (module_sp) { +if (size_to_read == 0) { + // Default to 8192 in case we can't find a memory region. +

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #101237)

@@ -3704,3 +3790,83 @@ ObjectFileELF::MapFileDataWritable(const FileSpec , uint64_t Size, return FileSystem::Instance().CreateWritableDataBuffer(file.GetPath(), Size, Offset); } + +std::optional

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #101237)

@@ -3664,7 +3730,27 @@ llvm::ArrayRef ObjectFileELF::ProgramHeaders() { } DataExtractor ObjectFileELF::GetSegmentData(const ELFProgramHeader ) { - return DataExtractor(m_data, H.p_offset, H.p_filesz); + // Try and read the program header from our cached m_data which can

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #101237)

@@ -402,6 +413,29 @@ class ObjectFileELF : public lldb_private::ObjectFile { /// .gnu_debugdata section or \c nullptr if an error occured or if there's no /// section with that name. std::shared_ptr GetGnuDebugDataObjectFile(); + + /// Get the bytes that represent the

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #101237)

@@ -873,33 +873,29 @@ Address ObjectFileELF::GetImageInfoAddress(Target *target) { if (!section_list) return Address(); - // Find the SHT_DYNAMIC (.dynamic) section. - SectionSP dynsym_section_sp( - section_list->FindSectionByType(eSectionTypeELFDynamicLinkInfo,

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #101237)

@@ -0,0 +1,58 @@ +// REQUIRES: system-linux, native labath wrote: I would like to see a test which uses an on-disk section-header-free object file. (Maybe you could base it off of llvm/test/tools/llvm-readobj/ELF/dynamic-reloc-no-section-headers.test). The

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #101237)

@@ -873,33 +873,29 @@ Address ObjectFileELF::GetImageInfoAddress(Target *target) { if (!section_list) return Address(); - // Find the SHT_DYNAMIC (.dynamic) section. - SectionSP dynsym_section_sp( - section_list->FindSectionByType(eSectionTypeELFDynamicLinkInfo,

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #101237)

@@ -2472,48 +2429,47 @@ size_t ObjectFileELF::ParseDynamicSymbols() { if (m_dynamic_symbols.size()) return m_dynamic_symbols.size(); - SectionList *section_list = GetSectionList(); - if (!section_list) + std::optional dynamic_data = GetDynamicData(); + if

[Lldb-commits] [lldb] [lldb] Updated lldb-server to spawn the child process and share socket on Windows (PR #101283)

https://github.com/labath commented: I think we should slow down a bit. For consistency, and to minimize the number of ifdefs, I believe windows and non-windows paths should use as similar approaches as possible. That means I think the end state should be that the posix path also uses a

[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

@@ -550,7 +588,7 @@ Stream::create(const Directory , const object::MinidumpFile ) { llvm_unreachable("Unhandled stream kind!"); } -Expected Object::create(const object::MinidumpFile ) { +Expected Object::create(object::MinidumpFile ) { labath wrote: Yeah,

[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

@@ -373,7 +373,6 @@ void yaml::MappingContextTraits::mapping( void yaml::MappingContextTraits::mapping( IO , MemoryDescriptor_64 , BinaryRef ) { mapRequiredHex(IO, "Start of Memory Range", Memory.StartOfMemoryRange); - mapRequiredHex(IO, "Data Size", Memory.DataSize);

[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

@@ -336,3 +336,52 @@ TEST(MinidumpYAML, ExceptionStream_ExtraParameter) { 0xab, 0xad, 0xca, 0xfe}), *ExpectedContext); } + +TEST(MinidumpYAML, MemoryRegion_64bit) { + SmallString<0> Storage; + auto ExpectedFile = toBinary(Storage,

[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

@@ -1,7 +1,7 @@ --- !minidump -Streams: +Streams: labath wrote: Please either revert these changes or put them in as a separate patch (you don't need to wait for a review on that). https://github.com/llvm/llvm-project/pull/101272

[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

@@ -336,3 +336,52 @@ TEST(MinidumpYAML, ExceptionStream_ExtraParameter) { 0xab, 0xad, 0xca, 0xfe}), *ExpectedContext); } + +TEST(MinidumpYAML, MemoryRegion_64bit) { + SmallString<0> Storage; + auto ExpectedFile = toBinary(Storage,

[Lldb-commits] [lldb] [llvm] [LLDB][Minidump] Fix ProcessMinidump::GetMemoryRegions to include 64b regions when /proc/pid maps are missing. (PR #101086)

labath wrote: > > Sounds good. Could you split off the lldb parts to a separate review though? > > @labath I think we need both, in order to fix `SBProcess` to return all > memory regions we need the LLDB change, which enables us to test if the > yaml2obj generates correctly I can believe

[Lldb-commits] [lldb] [lldb] Refactor TypeQuery::ContextMatches (PR #99305)

@@ -153,19 +127,89 @@ void TypeQuery::SetLanguages(LanguageSet languages) { bool TypeQuery::ContextMatches( llvm::ArrayRef context_chain) const { - if (GetExactMatch() || context_chain.size() == m_context.size()) -return ::contextMatches(context_chain, m_context); -

[Lldb-commits] [lldb] [lldb] Refactor TypeQuery::ContextMatches (PR #99305)

labath wrote: My idea for anonymous namespaces was basically to treat them as optional, so that you could get a match (even an "exact" match maybe?) for `(anonymous namespace)::Foo` with a pattern `Foo`. However, if a pattern explicitly contained an `(anonymous namespace)`, then this would

[Lldb-commits] [lldb] [lldb] Tolerate multiple compile units with the same DWO ID (PR #100577)

@@ -97,12 +97,14 @@ void DWARFUnit::ExtractUnitDIEIfNeeded() { *m_dwo_id, m_first_die.GetOffset())); return; // Can't fetch the compile unit from the dwo file. } - // If the skeleton compile unit gets its unit DIE parsed first, then this - // will fill in the

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

@@ -0,0 +1,459 @@ +//===-- DILAST.h *- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

@@ -0,0 +1,459 @@ +//===-- DILAST.h *- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

@@ -0,0 +1,446 @@ +//===-- DILAST.h *- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

@@ -0,0 +1,459 @@ +//===-- DILAST.h *- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

@@ -0,0 +1,459 @@ +//===-- DILAST.h *- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

@@ -0,0 +1,560 @@ +//===-- DILAST.cpp ===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

@@ -0,0 +1,560 @@ +//===-- DILAST.cpp ===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

@@ -0,0 +1,459 @@ +//===-- DILAST.h *- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

@@ -0,0 +1,459 @@ +//===-- DILAST.h *- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

@@ -0,0 +1,459 @@ +//===-- DILAST.h *- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

@@ -0,0 +1,560 @@ +//===-- DILAST.cpp ===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

@@ -0,0 +1,459 @@ +//===-- DILAST.h *- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

@@ -0,0 +1,459 @@ +//===-- DILAST.h *- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

@@ -0,0 +1,459 @@ +//===-- DILAST.h *- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

@@ -0,0 +1,459 @@ +//===-- DILAST.h *- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

https://github.com/labath commented: I still have a lot of comments, but I think we're making progress. The most important questions are about the parts where we appear to be reimplementing some existing lldb functionality. Basically all of the functionality for looking up names (for members,

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

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

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

@@ -0,0 +1,459 @@ +//===-- DILAST.h *- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)

labath wrote: > > The way this would work is by letting the platform instance > > delegate/upgrate/convert the platform connection into a gdbserver one. The > > way this would work would be something like this: > > > > 1. `lldb-server platform` would advertise (say in `qSupported`) its

[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)

labath wrote: > > Ok, so if I'm reading this right you're saying you saw no ETXTBSY errors > > with the current implementation --server flag. Is that correct ? > > Right. Initially I have marked #100670 as dependent on this. > > Ok, agreed. So, we can try to use O_CLOFORK. And simple solution

[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)

labath wrote: > > that could mean that something like `$CC hello.cc && ./a.out` could fail > > (what we're doing here isn't fundamentally different than that). > > The difference is that cc creates a.out and exits itself. But `lldb-server > platform` is still running after creating the

[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)

labath wrote: > > Does this refer the the forking implementation you get with the --server > > flag, or the serial implementation which only handles one connection at a > > time (without the flag)? > > I mean the `--server` flag. It is very hard to reproduce this issue with the > serial

[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)

labath wrote: > > If this is only really used for a "only for few requests via the platform > > protocol", then why not make the CWD a property of the platform object? > > (Either through a virtual filesystem, or just by having it as a string, and > > resolving things explicitly) > > It is

[Lldb-commits] [lldb] [LLDB] Improve ObjectFileELF files ability to load from memory. (PR #100900)

labath wrote: I like this idea a lot, but I have some reservations about the implementation. For one, I think this patch is too big. I once heard someone say "if you have bullet points in your patch description, then the patch is doing too much". While I don't think we should go as far as to

[Lldb-commits] [lldb] [LLDB][test] Provide a proper path to 'strip' utility for the LLDB API tests. (PR #100836)

https://github.com/labath commented: Could we standardize on `$(OBJCOPY) --strip-debug` instead? https://github.com/llvm/llvm-project/pull/100836 ___ lldb-commits mailing list lldb-commits@lists.llvm.org

[Lldb-commits] [lldb] [WIP][lldb][test] Add a new __compressed_pair layout to libcxx simulator tests (PR #99012)

https://github.com/labath approved this pull request. https://github.com/llvm/llvm-project/pull/99012 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)

labath wrote: > @labath > > > I wanted to change this code to use threads for a long time, but the idea > > of using a per-thread virtual file system absolutely terrifies me. That > > only works is all of the accesses go through the file system (no direct > > syscalls) and if we're very

[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)

@@ -324,6 +324,18 @@ Status PipePosix::ReadWithTimeout(void *buf, size_t size, bytes_read += result; if (bytes_read == size || result == 0) break; + +// This is the workaround for the following bug in Linux multithreading +// select()

[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)

@@ -456,21 +492,15 @@ ifeq (1, $(USE_SYSTEM_STDLIB)) endif CXXFLAGS += -nostdlib++ -nostdinc++ -cxx-isystem $(SDKROOT)/usr/include/c++/v1 LDFLAGS += -L$(SDKROOT)/usr/lib -Wl,-rpath,$(SDKROOT)/usr/lib -lc++ +else +ifneq (,$(findstring

[Lldb-commits] [lldb] [lldb][TypeSystemClang] Create VLAs of explicitly 0-size as ConstantArrayType (PR #100710)

https://github.com/labath approved this pull request. https://github.com/llvm/llvm-project/pull/100710 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)

labath wrote: > * thread 1 opens a file for writing (file descriptor A) and starts writing it > > * thread 2 starts launching a gdb server. It calls fork(), which creates > another process with a copy of fd A (the fd has the CLOEXEC flag set, but not > CLOFORK (the flag doesn't exist)) > > *

[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)

labath wrote: That *may* be how things works on windows(*), but I'm pretty sure it's not how things work on linux. A much more likely scenario is: 1. thread 1 opens a file for writing (file descriptor A) and starts writing it 2. thread 2 starts launching a gdb server. It calls fork(), which

[Lldb-commits] [lldb] [lldb][test] Add ABI library to Makefile.rules link flags (PR #99589)

https://github.com/labath approved this pull request. I suggest Monday. If anything breaks, at least there'll be someone around to do something about it. https://github.com/llvm/llvm-project/pull/99589 ___ lldb-commits mailing list

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

labath wrote: > One thing that's not entirely clear to me from the discussion so far: > apparently the public API rules allow adding an overload of > `SBProcess::Continue()` with a direction parameter. Do they allow just adding > a direction parameter to the existing overload _with a default

[Lldb-commits] [lldb] [lldb] Refactor TypeQuery::ContextMatches (PR #99305)

@@ -153,19 +127,89 @@ void TypeQuery::SetLanguages(LanguageSet languages) { bool TypeQuery::ContextMatches( llvm::ArrayRef context_chain) const { - if (GetExactMatch() || context_chain.size() == m_context.size()) -return ::contextMatches(context_chain, m_context); -

[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)

labath wrote: One way I can imagine this happening is if the FileSystem instance was local to a `GDBRemoteCommunicationServerPlatform` instance -- rather than the thread it happens to be (mostly) running on. This will require more changes to, basically, plumb the filesystem instance to every

[Lldb-commits] [lldb] [lldb][test][win][x86_64] Fix XFAIL and XPASS on LLDB API tests (PR #100477)

https://github.com/labath commented: This looks much better, and it looks like @dzhidzhoev is just about to remove some of the same XFAILS as well (in #100628). I suggest you two collaborate on the remaining ones. https://github.com/llvm/llvm-project/pull/100477

[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)

@@ -324,6 +324,18 @@ Status PipePosix::ReadWithTimeout(void *buf, size_t size, bytes_read += result; if (bytes_read == size || result == 0) break; + +// This is the workaround for the following bug in Linux multithreading +// select()

[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)

https://github.com/labath requested changes to this pull request. I wanted to change this code to use threads for a long time, but the idea of using a per-thread virtual file system absolutely terrifies me. That only works is all of the accesses go through the file system (no direct syscalls)

[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)

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

[Lldb-commits] [lldb] [lldb] Optimized lldb-server memory usage (PR #100666)

https://github.com/labath approved this pull request. https://github.com/llvm/llvm-project/pull/100666 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Optimized lldb-server memory usage (PR #100666)

@@ -1145,8 +1145,8 @@ Status GDBRemoteCommunication::StartDebugserverProcess( if (socket_pipe.CanWrite()) socket_pipe.CloseWriteFileDescriptor(); if (socket_pipe.CanRead()) { -char port_cstr[PATH_MAX] = {0}; -port_cstr[0] = '\0'; +//

[Lldb-commits] [lldb] [llvm] [lldb][RISCV] function calls support in lldb expressions (PR #99336)

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

[Lldb-commits] [lldb] [llvm] [lldb][RISCV] function calls support in lldb expressions (PR #99336)

@@ -0,0 +1,58 @@ +//===--- DirectToIndirectFCR.h - RISC-V specific pass -===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)

labath wrote: > If that's not what's happening right now, then we ought to fix it. Or at least, understand why is that impossible. https://github.com/llvm/llvm-project/pull/100659 ___ lldb-commits mailing list lldb-commits@lists.llvm.org

[Lldb-commits] [lldb] [lldb] Tolerate multiple compile units with the same DWO ID (PR #100577)

@@ -170,7 +170,7 @@ class DWARFUnit : public UserID { /// both cases correctly and avoids crashes. DWARFCompileUnit *GetSkeletonUnit(); - void SetSkeletonUnit(DWARFUnit *skeleton_unit); + bool LinkToSkeletonUnit(DWARFUnit _unit); labath wrote: It just

[Lldb-commits] [lldb] [lldb] Tolerate multiple compile units with the same DWO ID (PR #100577)

@@ -718,13 +720,11 @@ DWARFCompileUnit *DWARFUnit::GetSkeletonUnit() { return llvm::dyn_cast_or_null(m_skeleton_unit); } -void DWARFUnit::SetSkeletonUnit(DWARFUnit *skeleton_unit) { - // If someone is re-setting the skeleton compile unit backlink, make sure - // it is

[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)

@@ -456,21 +492,15 @@ ifeq (1, $(USE_SYSTEM_STDLIB)) endif CXXFLAGS += -nostdlib++ -nostdinc++ -cxx-isystem $(SDKROOT)/usr/include/c++/v1 LDFLAGS += -L$(SDKROOT)/usr/lib -Wl,-rpath,$(SDKROOT)/usr/lib -lc++ +else +ifneq (,$(findstring

[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)

@@ -267,7 +274,9 @@ endif CFLAGS += $(CFLAGS_EXTRAS) CXXFLAGS += -std=c++11 $(CFLAGS) $(ARCH_CXXFLAGS) LD = $(CC) -LDFLAGS ?= $(CFLAGS) +# Copy common options to the linker flags (dwarf, arch. & etc). +# Note: we get some 'garbage' options for linker here (such as -I,

[Lldb-commits] [lldb] [lldb] Tolerate multiple compile units with the same DWO ID (PR #100577)

https://github.com/labath created https://github.com/llvm/llvm-project/pull/100577 I ran into this when LTO completely emptied two compile units, so they ended up with the same hash (see #100375). Although, ideally, the compiler would try to ensure we don't end up with a hash collision even

[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)

labath wrote: > When we were setting up cross-platform build and testing config, we had a > multi-screen list of errors we had to solve. Also, we were unsure about the > environment in which we would run this. Therefore we decided to bulk > normalize all paths and some flags. But now I see

[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing Shell tests (PR #100476)

@@ -1,3 +1,4 @@ +# XFAIL: target=x86_64-{{.*}}-windows{{.*}} # Make sure lldb can handle filenames with single quotes in them. # RUN: %clang_host %p/Inputs/hello.c -g -o "%t-'pat" labath wrote: And this looks like you may have a different shell (one that

[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing Shell tests (PR #100476)

@@ -1,3 +1,4 @@ +# XFAIL: target=x86_64-{{.*}}-windows{{.*}} labath wrote: something like `system-windows && target-x86_64` ought to do it. However, like I said in the other review, I think we ought to figure out why are these failing for you.

[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing Shell tests (PR #100476)

@@ -1,3 +1,5 @@ +# XFAIL: target=x86_64-{{.*}}-windows{{.*}} labath wrote: This is particularly concerning, given that this test just operates on static binary data (expressed in yaml form). There should be nothing target-specific here. Maybe we could start

[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing Shell tests (PR #100476)

@@ -1,4 +1,5 @@ # UNSUPPORTED: system-windows +# XFAIL: target=x86_64-{{.*}}-windows{{.*}} labath wrote: This shouldn't be necessary given the UNSUPPORTED clause above. https://github.com/llvm/llvm-project/pull/100476

[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing API tests (PR #100477)

https://github.com/labath commented: I'm somewhat surprised to see this many x86 xfails, given that we already have an arm64 windows bot, and that none of the tests I see here are very architecture-specific. I wonder if this could be due to how you've configured your build. @DavidSpickett,

[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing API tests (PR #100477)

@@ -18,7 +18,7 @@ def test_set_use_source_cache_false(self): self.set_use_source_cache_and_test(False) @skipIf(hostoslist=no_match(["windows"])) -@skipIf(oslist=["windows"]) # Fails on windows 11 +@expectedFailureAll(oslist=["windows"])

[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing API tests (PR #100477)

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

[Lldb-commits] [lldb] [lldb][Linux] Parse, but don't store "comm" from /proc/stat file (PR #100387)

https://github.com/labath approved this pull request. Yikes, I didn't realize this was new code. @feg208, we need to fix this soon. I'm approving this because it strictly improves upon the current situation, but I don't think it's not a complete fix. I think we can skip over the `comm` field

[Lldb-commits] [lldb] [lldb] Correct format specifier for sscanf to prevent buffer overflow (NFC) (PR #94783)

labath wrote: > > The field this is consuming is actually 17 bytes long, because the process > > name is in parenthesis. > > Ok then I am confused how this ever worked, but it sounds like scanf was > never a great way to do this anyway? The field it's overwriting is in a struct, so it has a

[Lldb-commits] [lldb] [lldb] Correct format specifier for sscanf to prevent buffer overflow (NFC) (PR #94783)

https://github.com/labath commented: The field this is consuming is actually 17 bytes long, because the process name is in parenthesis. I suspect this will cause the function to reject any process whose name is longer than 13 characters. The name field is actually quite hard to parse this way

[Lldb-commits] [lldb] [llvm] [llvm]Added lib/Telemetry (PR #98528)

@@ -0,0 +1,619 @@ + +//===-- Telemetry.cpp -===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[Lldb-commits] [lldb] [llvm] [llvm]Added lib/Telemetry (PR #98528)

@@ -0,0 +1,153 @@ +#ifndef LLDB_CORE_TELEMETRY_H +#define LLDB_CORE_TELEMETRY_H + +#include +#include +#include +#include +#include +#include + +#include "lldb/Interpreter/CommandReturnObject.h" +#include "lldb/Utility/StructuredData.h" +#include "lldb/lldb-forward.h"

[Lldb-commits] [lldb] [llvm] [llvm]Added lib/Telemetry (PR #98528)

@@ -0,0 +1,153 @@ +#ifndef LLDB_CORE_TELEMETRY_H +#define LLDB_CORE_TELEMETRY_H + +#include +#include +#include +#include +#include +#include + +#include "lldb/Interpreter/CommandReturnObject.h" +#include "lldb/Utility/StructuredData.h" +#include "lldb/lldb-forward.h"

[Lldb-commits] [lldb] [llvm] [llvm]Added lib/Telemetry (PR #98528)

@@ -0,0 +1,619 @@ + +//===-- Telemetry.cpp -===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[Lldb-commits] [lldb] [llvm] [llvm]Added lib/Telemetry (PR #98528)

@@ -0,0 +1,153 @@ +#ifndef LLDB_CORE_TELEMETRY_H +#define LLDB_CORE_TELEMETRY_H + +#include +#include +#include +#include +#include +#include + +#include "lldb/Interpreter/CommandReturnObject.h" +#include "lldb/Utility/StructuredData.h" +#include "lldb/lldb-forward.h"

[Lldb-commits] [lldb] [llvm] [llvm]Added lib/Telemetry (PR #98528)

@@ -34,6 +34,7 @@ #include "lldb/API/SBTypeNameSpecifier.h" #include "lldb/API/SBTypeSummary.h" #include "lldb/API/SBTypeSynthetic.h" +#include labath wrote: `` is [banned](https://llvm.org/docs/CodingStandards.html#include-iostream-is-forbidden) in llvm,

[Lldb-commits] [lldb] [llvm] [llvm]Added lib/Telemetry (PR #98528)

@@ -0,0 +1,619 @@ + +//===-- Telemetry.cpp -===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[Lldb-commits] [lldb] [llvm] [llvm]Added lib/Telemetry (PR #98528)

@@ -9,10 +9,12 @@ #ifndef LLDB_API_SBDEBUGGER_H #define LLDB_API_SBDEBUGGER_H +#include labath wrote: Is this used anywhere? https://github.com/llvm/llvm-project/pull/98528 ___ lldb-commits mailing list

[Lldb-commits] [lldb] [llvm] [llvm]Added lib/Telemetry (PR #98528)

@@ -0,0 +1,619 @@ + labath wrote: delete empty line https://github.com/llvm/llvm-project/pull/98528 ___ lldb-commits mailing list lldb-commits@lists.llvm.org

[Lldb-commits] [lldb] [llvm] [llvm]Added lib/Telemetry (PR #98528)

@@ -0,0 +1,619 @@ + +//===-- Telemetry.cpp -===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier:

[Lldb-commits] [lldb] [llvm] [llvm]Added lib/Telemetry (PR #98528)

@@ -0,0 +1,153 @@ +#ifndef LLDB_CORE_TELEMETRY_H +#define LLDB_CORE_TELEMETRY_H + +#include +#include +#include +#include +#include +#include + +#include "lldb/Interpreter/CommandReturnObject.h" +#include "lldb/Utility/StructuredData.h" +#include "lldb/lldb-forward.h"

[Lldb-commits] [lldb] [llvm] [llvm]Added lib/Telemetry (PR #98528)

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

[Lldb-commits] [lldb] [llvm] [llvm]Added lib/Telemetry (PR #98528)

https://github.com/labath commented: I've made one pass over the PR. I think this would be easier to review if it was split into multiple patches: - core llvm infrastructure - core lldb infrastructure - ~one patch per event type I think the biggest hurdle will be finding someone to approve the

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

https://github.com/labath edited 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

  1   2   3   4   5   6   7   8   9   10   >