@@ -983,6 +1005,73 @@ llvm::Error
ProcessElfCore::ParseThreadContextsFromNoteSegment(
}
}
+bool ProcessElfCore::IsElf(const lldb::addr_t address) {
+ uint8_t buf[4];
+ Status error;
+ size_t byte_read = ReadMemory(address, buf, 4, error);
+ if (byte_read != 4)
+
@@ -983,6 +1005,73 @@ llvm::Error
ProcessElfCore::ParseThreadContextsFromNoteSegment(
}
}
+bool ProcessElfCore::IsElf(const lldb::addr_t address) {
+ uint8_t buf[4];
+ Status error;
+ size_t byte_read = ReadMemory(address, buf, 4, error);
+ if (byte_read != 4)
+
@@ -1649,6 +1679,26 @@ class Process : public
std::enable_shared_from_this,
lldb::addr_t ReadPointerFromMemory(lldb::addr_t vm_addr, Status );
+ /// Find a string within a memory region.
+ ///
+ /// This function searches for the string represented by the provided
@@ -33,12 +35,17 @@
#include "Plugins/Process/elf-core/RegisterUtilities.h"
#include "ProcessElfCore.h"
#include "ThreadElfCore.h"
+#include "lldb/lldb-types.h"
using namespace lldb_private;
namespace ELF = llvm::ELF;
LLDB_PLUGIN_DEFINE(ProcessElfCore)
+#define
@@ -117,6 +117,13 @@ class ProcessElfCore : public
lldb_private::PostMortemProcess {
lldb::addr_t end;
lldb::addr_t file_ofs;
std::string path;
+lldb_private::UUID uuid; //.note.gnu.build-id
+ };
+
+ struct Section_Note {
+uint32_t namesz;
+uint32_t
@@ -983,6 +1005,73 @@ llvm::Error
ProcessElfCore::ParseThreadContextsFromNoteSegment(
}
}
+bool ProcessElfCore::IsElf(const lldb::addr_t address) {
+ uint8_t buf[4];
+ Status error;
+ size_t byte_read = ReadMemory(address, buf, 4, error);
+ if (byte_read != 4)
+
@@ -1649,6 +1679,26 @@ class Process : public
std::enable_shared_from_this,
lldb::addr_t ReadPointerFromMemory(lldb::addr_t vm_addr, Status );
+ /// Find a string within a memory region.
clayborg wrote:
Change to:
```
/// Find bytes within a memory
@@ -1649,6 +1679,26 @@ class Process : public
std::enable_shared_from_this,
lldb::addr_t ReadPointerFromMemory(lldb::addr_t vm_addr, Status );
+ /// Find a string within a memory region.
+ ///
+ /// This function searches for the string represented by the provided
https://github.com/clayborg closed
https://github.com/llvm/llvm-project/pull/92002
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/clayborg approved this pull request.
https://github.com/llvm/llvm-project/pull/92002
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -6335,16 +6335,51 @@ static void AddRegion(const MemoryRegionInfo ,
bool try_dirty_pages,
ranges.push_back(CreateCoreFileMemoryRange(region));
}
+static void
+SaveOffRegionsWithStackPointers(Process ,
+ const MemoryRegionInfos ,
+
@@ -490,9 +491,12 @@ findStackHelper(const lldb::ProcessSP _sp,
uint64_t rsp) {
return llvm::createStringError(
std::errc::not_supported,
"unable to load stack segment of the process");
-
- const addr_t addr = range_info.GetRange().GetRangeBase();
-
@@ -6335,16 +6335,51 @@ static void AddRegion(const MemoryRegionInfo ,
bool try_dirty_pages,
ranges.push_back(CreateCoreFileMemoryRange(region));
}
+static void
+SaveOffRegionsWithStackPointers(Process ,
+ const MemoryRegionInfos ,
+
https://github.com/clayborg requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/92002
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/92002
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -6335,16 +6335,51 @@ static void AddRegion(const MemoryRegionInfo ,
bool try_dirty_pages,
ranges.push_back(CreateCoreFileMemoryRange(region));
}
+static void
+SaveOffRegionsWithStackPointers(Process ,
+ const MemoryRegionInfos ,
+
@@ -6410,12 +6410,20 @@ GetCoreFileSaveRangesStackOnly(Process ,
if (!reg_ctx_sp)
continue;
const addr_t sp = reg_ctx_sp->GetSP();
+const size_t red_zone = process.GetABI()->GetRedZoneSize();
lldb_private::MemoryRegionInfo sp_region;
if
@@ -731,8 +746,11 @@ class Debugger : public
std::enable_shared_from_this,
lldb::TargetSP m_dummy_target_sp;
Diagnostics::CallbackID m_diagnostics_callback_id;
- lldb_private::DebuggerDestroyCallback m_destroy_callback = nullptr;
- void *m_destroy_callback_baton =
@@ -766,6 +768,12 @@ class CommandInterpreter : public Broadcaster,
CommandUsageMap m_command_usages;
StreamString m_transcript_stream;
+
+ /// Contains a list of handled commands, output and error. Each element in
+ /// the list is a dictionary with three keys:
@@ -766,6 +768,12 @@ class CommandInterpreter : public Broadcaster,
CommandUsageMap m_command_usages;
StreamString m_transcript_stream;
+
+ /// Contains a list of handled commands, output and error. Each element in
+ /// the list is a dictionary with three keys:
@@ -571,6 +571,15 @@ SBStructuredData SBCommandInterpreter::GetStatistics() {
return data;
}
+SBStructuredData SBCommandInterpreter::GetTranscript() {
+ LLDB_INSTRUMENT_VA(this);
+
+ SBStructuredData data;
+ if (IsValid())
+
@@ -766,6 +768,12 @@ class CommandInterpreter : public Broadcaster,
CommandUsageMap m_command_usages;
StreamString m_transcript_stream;
+
+ /// Contains a list of handled commands, output and error. Each element in
+ /// the list is a dictionary with three keys:
@@ -743,9 +743,28 @@ DebuggerSP
Debugger::CreateInstance(lldb::LogOutputCallback log_callback,
}
void Debugger::HandleDestroyCallback() {
- if (m_destroy_callback) {
-m_destroy_callback(GetID(), m_destroy_callback_baton);
-m_destroy_callback = nullptr;
+
@@ -0,0 +1,102 @@
+//===-- SBAddressRange.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:
clayborg wrote:
> Can we make this less brute force? I believe searching for the Build ID Note
> should be a completely deterministic process, without the need for
> heuristics. You start with the elf header, find the program headers, iterate
> to find the PT_NOTE segment (there could be more
@@ -0,0 +1,78 @@
+//===-- SBAddressRange.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:
@@ -0,0 +1,58 @@
+//===-- SBAddressRangeList.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:
@@ -0,0 +1,13 @@
+%extend lldb::SBAddressRangeList {
+#ifdef SWIGPYTHON
+%pythoncode%{
+def __len__(self):
+ '''Return the number of address ranges in a lldb.SBAddressRangeList
object.'''
+ return self.GetSize()
+
+def __iter__(self):
+ '''Iterate over
@@ -0,0 +1,13 @@
+%extend lldb::SBAddressRangeList {
clayborg wrote:
If we add a method to SBAddressRangeList:
```
bool GetDescription(lldb::SBStream );
```
Then we can add this to this file:
```
STRING_EXTENSION_OUTSIDE(SBAddressRangeList)
```
And then we can
https://github.com/clayborg commented:
We might want SBAddressRange and SBAddressRangeList to have methods:
```
bool GetDescription(lldb::SBStream );
```
Then make sure we add stuff to the .i files so python `str()` calls this.
We do this in many other classes.
@@ -0,0 +1,13 @@
+%extend lldb::SBAddressRangeList {
+#ifdef SWIGPYTHON
+%pythoncode%{
+def __len__(self):
+ '''Return the number of address ranges in a lldb.SBAddressRangeList
object.'''
+ return self.GetSize()
+
+def __iter__(self):
+ '''Iterate over
@@ -983,6 +995,44 @@ llvm::Error
ProcessElfCore::ParseThreadContextsFromNoteSegment(
}
}
+bool ProcessElfCore::IsElf(const NT_FILE_Entry entry) {
+ const uint8_t elf_header[4] = {0x7f, 0x45, 0x4c,
+ 0x46}; // ELF file begin with this 4
@@ -983,6 +995,44 @@ llvm::Error
ProcessElfCore::ParseThreadContextsFromNoteSegment(
}
}
+bool ProcessElfCore::IsElf(const NT_FILE_Entry entry) {
+ const uint8_t elf_header[4] = {0x7f, 0x45, 0x4c,
+ 0x46}; // ELF file begin with this 4
@@ -983,6 +995,44 @@ llvm::Error
ProcessElfCore::ParseThreadContextsFromNoteSegment(
}
}
+bool ProcessElfCore::IsElf(const NT_FILE_Entry entry) {
+ const uint8_t elf_header[4] = {0x7f, 0x45, 0x4c,
+ 0x46}; // ELF file begin with this 4
@@ -983,6 +995,44 @@ llvm::Error
ProcessElfCore::ParseThreadContextsFromNoteSegment(
}
}
+bool ProcessElfCore::IsElf(const NT_FILE_Entry entry) {
+ const uint8_t elf_header[4] = {0x7f, 0x45, 0x4c,
+ 0x46}; // ELF file begin with this 4
@@ -983,6 +995,44 @@ llvm::Error
ProcessElfCore::ParseThreadContextsFromNoteSegment(
}
}
+bool ProcessElfCore::IsElf(const NT_FILE_Entry entry) {
+ const uint8_t elf_header[4] = {0x7f, 0x45, 0x4c,
+ 0x46}; // ELF file begin with this 4
@@ -977,35 +977,6 @@ class CommandObjectMemoryFind : public CommandObjectParsed
{
Options *GetOptions() override { return _option_group; }
protected:
- class ProcessMemoryIterator {
- public:
-ProcessMemoryIterator(ProcessSP process_sp, lldb::addr_t base)
-:
@@ -3191,6 +3191,33 @@ Status Process::Halt(bool clear_thread_plans, bool
use_run_lock) {
return Status();
}
+lldb::addr_t Process::FastSearch(lldb::addr_t low, lldb::addr_t high,
clayborg wrote:
rename to `FindInMemory`
@@ -983,6 +995,44 @@ llvm::Error
ProcessElfCore::ParseThreadContextsFromNoteSegment(
}
}
+bool ProcessElfCore::IsElf(const NT_FILE_Entry entry) {
+ const uint8_t elf_header[4] = {0x7f, 0x45, 0x4c,
+ 0x46}; // ELF file begin with this 4
@@ -117,6 +117,8 @@ class ProcessElfCore : public
lldb_private::PostMortemProcess {
lldb::addr_t end;
lldb::addr_t file_ofs;
std::string path;
+lldb_private::UUID
+uuid; // extracted from .note.gnu.build-id section from core file
@@ -983,6 +995,44 @@ llvm::Error
ProcessElfCore::ParseThreadContextsFromNoteSegment(
}
}
+bool ProcessElfCore::IsElf(const NT_FILE_Entry entry) {
+ const uint8_t elf_header[4] = {0x7f, 0x45, 0x4c,
+ 0x46}; // ELF file begin with this 4
@@ -983,6 +995,44 @@ llvm::Error
ProcessElfCore::ParseThreadContextsFromNoteSegment(
}
}
+bool ProcessElfCore::IsElf(const NT_FILE_Entry entry) {
+ const uint8_t elf_header[4] = {0x7f, 0x45, 0x4c,
+ 0x46}; // ELF file begin with this 4
@@ -983,6 +995,44 @@ llvm::Error
ProcessElfCore::ParseThreadContextsFromNoteSegment(
}
}
+bool ProcessElfCore::IsElf(const NT_FILE_Entry entry) {
+ const uint8_t elf_header[4] = {0x7f, 0x45, 0x4c,
+ 0x46}; // ELF file begin with this 4
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/92078
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -158,6 +160,15 @@ class ProcessElfCore : public
lldb_private::PostMortemProcess {
// Returns number of thread contexts stored in the core file
uint32_t GetNumThreadContexts();
+ // Populate gnu uuid for each NT_FILE entry
+ void UpdateBuildIdForNTFileEntries();
+
+
https://github.com/clayborg requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/92078
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
clayborg wrote:
> > I forgot to ask, what is the motivation behind this change? Is there
> > something you can't do with the SBAPI right now or that is better expressed
> > with SBAddressRange and SBAddressRangeList?
>
> Yes, I want to add the following API:
>
> lldb::SBError
@@ -6410,12 +6410,20 @@ GetCoreFileSaveRangesStackOnly(Process ,
if (!reg_ctx_sp)
continue;
const addr_t sp = reg_ctx_sp->GetSP();
+const size_t red_zone = process.GetABI()->GetRedZoneSize();
lldb_private::MemoryRegionInfo sp_region;
if
https://github.com/clayborg requested changes to this pull request.
Change look good for the `GetCoreFileSaveRangesStackOnly`, but we want this to
work for the other two modes `modified-memory` and `full`. So we need to fix
`GetCoreFileSaveRangesFull` and `GetCoreFileSaveRangesDirtyOnly`.
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/92002
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,63 @@
+//===-- SBAddressRange.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:
@@ -0,0 +1,63 @@
+//===-- SBAddressRange.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:
@@ -0,0 +1,3 @@
+#include
+
+int main() { std::cout << "Hello World!" << std::endl; }
clayborg wrote:
No need to use here right? I would just do a simpler `main`:
```
int main() {
return 0;
}
```
(remove `#include` and use of `std::cout`). This will reduce
@@ -0,0 +1,130 @@
+
+//===-- SBAddressRangeList.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:
@@ -219,6 +219,16 @@ lldb::SBAddress SBBlock::GetRangeEndAddress(uint32_t idx) {
return sb_addr;
}
+lldb::SBAddressRange SBBlock::GetRangeAtIndex(uint32_t idx) {
+ LLDB_INSTRUMENT_VA(this, idx);
+
+ lldb::SBAddressRange sb_range;
+ if (m_opaque_ptr) {
+
@@ -0,0 +1,58 @@
+//===-- SBAddressRangeList.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:
@@ -0,0 +1,78 @@
+//===-- SBAddressRange.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:
@@ -0,0 +1,78 @@
+//===-- SBAddressRange.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:
@@ -52,6 +53,8 @@ class LLDB_API SBBlock {
lldb::SBAddress GetRangeEndAddress(uint32_t idx);
+ lldb::SBAddressRange GetRangeAtIndex(uint32_t idx);
+
clayborg wrote:
Use `SBAddressRangeList` here:
```
SBAddressRangeList GetRanges();
```
@@ -0,0 +1,78 @@
+//===-- SBAddressRange.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:
@@ -0,0 +1,58 @@
+//===-- SBAddressRangeList.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:
@@ -0,0 +1,63 @@
+//===-- SBAddressRange.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:
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/clayborg requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
I’ve been too stunned to find the words today – but you have all said it so
beautifully. I had heard so much about Lou, the mysterious yoga teacher who
had swept Claire off her feet and blazed all sorts of new trails with her in
New Zealand, before meeting him at the 2015 reunion, and he was
Revert "drm/nouveau/firmware: Fix SG_DEBUG error with nvkm_firmware_ctor()"
a222a6470d7eea91193946e8162066fa88da64c2
The errors I reported are the same as those quoted in the pull request for the
revert.
On 13/05/2024 08:43, Jani Nikula wrote:
> On Sat, 11 May 2024, Chris Clayton
On 08/05/2024 20:38, Chris Clayton wrote:
>
>
> On 08/05/2024 16:54, Daniel Vetter wrote:
>> On Wed, May 08, 2024 at 09:02:02AM +0100, Chris Clayton wrote:
>>> Hi,
>>>
>>> I'm running the latest development kernel - 6.9.0-rc7+ (HEAD is
&g
https://github.com/clayborg requested changes to this pull request.
We should make this thread safe. It can only help and this isn't an API which
gets called all of the time, so performance isn't an issue. A few inline
comments
https://github.com/llvm/llvm-project/pull/89868
@@ -731,8 +747,11 @@ class Debugger : public
std::enable_shared_from_this,
lldb::TargetSP m_dummy_target_sp;
Diagnostics::CallbackID m_diagnostics_callback_id;
- lldb_private::DebuggerDestroyCallback m_destroy_callback = nullptr;
- void *m_destroy_callback_baton =
@@ -1689,35 +1689,56 @@ void
SBDebugger::SetLoggingCallback(lldb::LogOutputCallback log_callback,
void SBDebugger::SetDestroyCallback(
lldb::SBDebuggerDestroyCallback destroy_callback, void *baton) {
LLDB_INSTRUMENT_VA(this, destroy_callback, baton);
+
if
@@ -1689,35 +1689,56 @@ void
SBDebugger::SetLoggingCallback(lldb::LogOutputCallback log_callback,
void SBDebugger::SetDestroyCallback(
lldb::SBDebuggerDestroyCallback destroy_callback, void *baton) {
LLDB_INSTRUMENT_VA(this, destroy_callback, baton);
+
if
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/89868
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
clayborg wrote:
> we should probably fix the underlying issue instead: #77696
We still have binaries that are floating around for now that contain this issue
and this was causing crashes. So it would be nice to fix this in LLDB for now
and back this out after we have a stable and trustable
clayborg wrote:
> we should probably fix the underlying issue instead: #77696
This is one fix that is needed. Quoted from an e-mail chain:
> I need to find my notes from those days, but I don't think we did. As Greg
> points out, the standard forbids forward declarations in debug_names;
clayborg wrote:
> The change/explanation looks intuitive, but I remember having seen DIE entry
> with `DW_AT_declaration (true)` but is not a forward declaration (it is a
> definition and has other attributes) . Will we cause regression in that case?
No, it is ok for `DW_AT_declaration(true)`
https://github.com/clayborg updated
https://github.com/llvm/llvm-project/pull/91808
>From 0cc1be6988e6ab5498151f32485f525a66133be2 Mon Sep 17 00:00:00 2001
From: Greg Clayton
Date: Fri, 10 May 2024 13:49:22 -0700
Subject: [PATCH] Improve performance of .debug_names lookups when
DW_IDX_par
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/91808
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
he .debug_names table will point to the DIE at offset 0x0090cdd5. These
entries cause our type lookups to try and parse a TON of forward declarations
and waste time and resources.
This fix makes sure when/if we find an entry in the .debug_names table, we
don't process it if it has a DW_AT_declaration
@@ -2343,7 +2343,10 @@ bool DWARFASTParserClang::CompleteTypeFromDWARF(const
DWARFDIE ,
// clang::ExternalASTSource queries for this type.
m_ast.SetHasExternalStorage(clang_type.GetOpaqueQualType(), false);
- if (!die)
+ ParsedDWARFTypeAttributes attrs(die);
+ bool
https://github.com/clayborg approved this pull request.
This does fix things on your side. I will take care of a new PR for not
searching all definition DIEs from the .debug_names.
https://github.com/llvm/llvm-project/pull/91799
___
lldb-commits
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/91799
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/clayborg commented:
Let me verify this works. I would also like this to fix:
```
bool DebugNamesDWARFIndex::ProcessEntry(
const DebugNames::Entry ,
llvm::function_ref callback) {
std::optional ref = ToDIERef(entry);
if (!ref)
return true;
SymbolFileDWARF =
clayborg wrote:
See the `/// <<< newly added for fix` comments for the new lines
https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
clayborg wrote:
Ok, I found the issue. `.debug_names` tables with `DW_IDX_parent` entries,
might contain tons of entries for forward declared classes because in my
example `std::ios_base` is the parent declaration context for `seekdir`,
`openmode`, and `iostate` so `.debug_names` entries for
clayborg wrote:
Is `SymbolFileDWARF::CompleteType(...)` responsible for trying to find a
non-declaration DIE first? The issue might arise from having a .debug_names
table that has `DW_IDX_parent` entries that means that there might be forward
declarations included in the DWARF index.
clayborg wrote:
This is causing a clang assertion due:
```
(lldb) type lookup std::ios_base
Assertion failed: (DD && "queried property of class with no definition"),
function data, file DeclCXX.h, line 464.
bt
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = hit program
@@ -147,96 +148,111 @@ class ProcessInstanceInfo : public ProcessInfo {
ProcessInstanceInfo() = default;
ProcessInstanceInfo(const char *name, const ArchSpec , lldb::pid_t pid)
- : ProcessInfo(name, arch, pid), m_euid(UINT32_MAX), m_egid(UINT32_MAX),
-
clayborg wrote:
If your register has fields, you can set its format to be eFormatEnum by
default. Each register defines how it gets displayed when we query the dynamic
register information from the `lldb-server` or `debugserver`
https://github.com/llvm/llvm-project/pull/90059
https://github.com/clayborg requested changes to this pull request.
So each `ValueObject` has the ability to show its value as an enumeration if
its format is set to `eFormatEnum`. If the format is set to `eFormatHex`,
`eFormatUnsigned`, or `eFormatSigned`, then we show the numeric value.
@@ -144,6 +144,19 @@ class ProcessInstanceInfo : public ProcessInfo {
long int tv_usec = 0;
};
+ enum class ProcessState {
+Unknown,
+Dead,
+DiskSleep,
+Idle,
+Paging,
+Parked,
+Running,
+Sleeping,
+TracedOrStopped,
+Zombie,
+
@@ -12,6 +12,9 @@
#include "lldb/Utility/ProcessInfo.h"
#include "gtest/gtest.h"
+#include
+#include
clayborg wrote:
This is fine if this is a host test, so nothing needs to be done. We are
expecting linux + posix here which is fine.
@@ -254,6 +280,8 @@ class ProcessInstanceInfo : public ProcessInfo {
struct timespec m_system_time {};
struct timespec m_cumulative_user_time {};
struct timespec m_cumulative_system_time {};
+ std::optional m_priority_value = std::nullopt;
+ bool m_zombie = false;
@@ -91,14 +87,16 @@ static bool GetStatusInfo(::pid_t Pid, ProcessInstanceInfo
,
if (Rest.empty())
return false;
StatFields stat_fields;
- if (sscanf(Rest.data(),
- "%d %s %c %d %d %d %d %d %u %lu %lu %lu %lu %lu %lu %ld %ld",
- _fields.pid,
https://github.com/clayborg approved this pull request.
Sounds good, thanks for the clarification.
https://github.com/llvm/llvm-project/pull/91591
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
@@ -23,6 +23,8 @@ class Symtab {
public:
typedef std::vector IndexCollection;
typedef UniqueCStringMap NameToIndexMap;
+ typedef std::map
+ FileAddressToAddressClassMap;
clayborg wrote:
You might want to use a llvm::DenseMap if possible. std::map
https://github.com/clayborg commented:
I can't remember: does terminate come before disconnecting? Or is it the other
way around?
https://github.com/llvm/llvm-project/pull/91591
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://github.com/clayborg commented:
How many notifications happen during an expression? We want to make sure this
doesn't slow down expression evaluation by any appreciable amount. If we spam
these notifications, without having any throttling in place (I have an open
patch for this I
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/91544
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -12,6 +12,9 @@
#include "lldb/Utility/ProcessInfo.h"
#include "gtest/gtest.h"
+#include
+#include
clayborg wrote:
it is ok to include this header file here because this is a linux specific host
test.
https://github.com/llvm/llvm-project/pull/91544
@@ -17,6 +17,7 @@
#include
#include
+#include
clayborg wrote:
Not every OS will have this header file, so I am not sure we can/should be
importing this header. Windows build will most likely fail and any non unix
based OS as well.
1 - 100 of 21726 matches
Mail list logo
