Michael137 wrote:
> I am somewhat worried about this slowing down the actual operations it is
> reporting progress on. I didn't really measure this, but intuitively, I'd
> expect that a one of these operations (parsing/importing one type) would be
> pretty fast, and that the whole process take
DavidSpickett wrote:
> The Symtab class is generic, while the approach of marking address types via
> fake symtab symbols is (I think) an elf invention.
I didn't see any use of `AddressClass::eCodeAlternateISA` outside of
ObjectFileELF so I think you're right.
I'll go with this PR then.
http
Author: David Spickett
Date: 2024-05-10T09:20:48+01:00
New Revision: a76518cadc5eaa6b6d07334e2b5bc08382aabe49
URL:
https://github.com/llvm/llvm-project/commit/a76518cadc5eaa6b6d07334e2b5bc08382aabe49
DIFF:
https://github.com/llvm/llvm-project/commit/a76518cadc5eaa6b6d07334e2b5bc08382aabe49.diff
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/91585
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/91603
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
Went with https://github.com/llvm/llvm-project/pull/91585 instead.
https://github.com/llvm/llvm-project/pull/91603
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commi
@@ -23,6 +23,8 @@ class Symtab {
public:
typedef std::vector IndexCollection;
typedef UniqueCStringMap NameToIndexMap;
+ typedef std::map
+ FileAddressToAddressClassMap;
DavidSpickett wrote:
Yes, we binary search it later. I will at least add a comme
DavidSpickett wrote:
There are a couple in MachO actually but you're right, different mechanism
being used.
https://github.com/llvm/llvm-project/pull/91585
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailma
@@ -87,8 +105,15 @@ SymbolVendorELF::CreateInstance(const lldb::ModuleSP
&module_sp,
FileSpecList search_paths = Target::GetDefaultDebugFileSearchPaths();
FileSpec dsym_fspec =
PluginManager::LocateExecutableSymbolFile(module_spec, search_paths);
- if (!dsym_fspec)
DavidSpickett wrote:
I've fixed the underlying issue on Arm, you do not need to make any changes to
this code to fix it. It should "just work" now.
I see some unresolved comments about other test failures, and if I reland this
I'll get all the buildbot emails and have no clue what to do to fix
Author: David Spickett
Date: 2024-05-10T09:25:03Z
New Revision: 1aca8ed5a7eeed264fdc2694deca8a4a4dba3689
URL:
https://github.com/llvm/llvm-project/commit/1aca8ed5a7eeed264fdc2694deca8a4a4dba3689
DIFF:
https://github.com/llvm/llvm-project/commit/1aca8ed5a7eeed264fdc2694deca8a4a4dba3689.diff
LOG
kevinfrei wrote:
Thanks for the diagnostics & fix. I really appreciate it. I'm on vacation this
week, so I'll get this ready & relanded next Monday.
https://github.com/llvm/llvm-project/pull/90622
___
lldb-commits mailing list
lldb-commits@lists.llvm.
@@ -12,6 +12,9 @@
#include "lldb/Utility/ProcessInfo.h"
#include "gtest/gtest.h"
+#include
+#include
emaste wrote:
Much of this file would work just fine on FreeBSD as well so that might make
sense, although I'm not sure what the best structure would be --
https://github.com/walter-erquinigo approved this pull request.
lgtm
https://github.com/llvm/llvm-project/pull/91688
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
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
https://lists.llvm.org/cgi-bin/mailman/listinfo
jimingham wrote:
I'm not sure checking the debugger here resolves the difficulty I pointed out
earlier. If I make an SBStream and call SBBreakpoint::GetDescription, I will
have passed in an SBStream with `use_color` explicitly off. It still seems to
me that should take precedence over the de
@@ -91,14 +87,16 @@ static bool GetStatusInfo(::pid_t Pid, ProcessInstanceInfo
&ProcessInfo,
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",
- &st
@@ -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;
-
@@ -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.
https://github.com/ll
@@ -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,
+ };
Author: Zequan Wu
Date: 2024-05-10T12:26:52-04:00
New Revision: 9a7262c2601874e5aa64c5db19746770212d4b44
URL:
https://github.com/llvm/llvm-project/commit/9a7262c2601874e5aa64c5db19746770212d4b44
DIFF:
https://github.com/llvm/llvm-project/commit/9a7262c2601874e5aa64c5db19746770212d4b44.diff
LOG
https://github.com/ZequanWu closed
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
jeffreytan81 wrote:
@jimingham, friendly ping. @clayborg mentioned that you are the sole domain
expert on ThreadPlan. Can you help to review this change? Thanks
https://github.com/llvm/llvm-project/pull/90930
___
lldb-commits mailing list
lldb-commits
Author: Pavel Labath
Date: 2024-05-10T18:56:21+02:00
New Revision: 871f4839f988a1ef59ea0371e0f25c8651a899f2
URL:
https://github.com/llvm/llvm-project/commit/871f4839f988a1ef59ea0371e0f25c8651a899f2
DIFF:
https://github.com/llvm/llvm-project/commit/871f4839f988a1ef59ea0371e0f25c8651a899f2.diff
https://github.com/labath closed https://github.com/llvm/llvm-project/pull/91591
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Alex Langford
Date: 2024-05-10T10:00:36-07:00
New Revision: 3bde7983986d8ce637f6bb506860859249787751
URL:
https://github.com/llvm/llvm-project/commit/3bde7983986d8ce637f6bb506860859249787751
DIFF:
https://github.com/llvm/llvm-project/commit/3bde7983986d8ce637f6bb506860859249787751.diff
https://github.com/bulbazord closed
https://github.com/llvm/llvm-project/pull/91685
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jimingham wrote:
Thanks for working up this patch. I should be able to get time to look at this
next week.
https://github.com/llvm/llvm-project/pull/90930
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailma
@@ -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;
-
https://github.com/feg208 updated
https://github.com/llvm/llvm-project/pull/91544
>From dbf56b2ebe93d2f3ef6e41bceb7359f6e10ae38d Mon Sep 17 00:00:00 2001
From: Fred Grim
Date: Wed, 8 May 2024 15:36:16 -0700
Subject: [PATCH] [lldb] Adds additional fields to ProcessInfo
To implement SaveCore for
@@ -91,14 +87,16 @@ static bool GetStatusInfo(::pid_t Pid, ProcessInstanceInfo
&ProcessInfo,
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",
- &st
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.
Can
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
@@ -147,96 +148,111 @@ class ProcessInstanceInfo : public ProcessInfo {
ProcessInstanceInfo() = default;
ProcessInstanceInfo(const char *name, const ArchSpec &arch, lldb::pid_t pid)
- : ProcessInfo(name, arch, pid), m_euid(UINT32_MAX), m_egid(UINT32_MAX),
-m_p
https://github.com/hawkinsw commented:
Sorry for the nits! I am not smart enough to contribute on the technical
merits, so I am trying to find some way to help!
https://github.com/llvm/llvm-project/pull/91544
___
lldb-commits mailing list
lldb-commits
https://github.com/hawkinsw 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
@@ -115,13 +124,19 @@ static bool GetStatusInfo(::pid_t Pid,
ProcessInstanceInfo &ProcessInfo,
return ts;
};
+ // priority (nice) values run from 19 to -20 inclusive (in linux). In the
hawkinsw wrote:
```suggestion
// Priority (nice) values run from
@@ -70,6 +71,12 @@ struct StatFields {
long unsigned stime;
long cutime;
long cstime;
+ // in proc_pid_stat(5) this field is specified as priority
+ // but documented as realtime priority. To keep with the adopted
+ // nomenclature in ProcessInstanceInfo we adopt the d
@@ -86,4 +89,22 @@ TEST_F(HostTest, GetProcessInfo) {
ProcessInstanceInfo::timespec next_user_time = Info.GetUserTime();
ASSERT_TRUE(user_time.tv_sec <= next_user_time.tv_sec ||
user_time.tv_usec <= next_user_time.tv_usec);
+
+ struct rlimit rlim;
+ EXPECT_E
@@ -70,6 +71,12 @@ struct StatFields {
long unsigned stime;
long cutime;
long cstime;
+ // in proc_pid_stat(5) this field is specified as priority
+ // but documented as realtime priority. To keep with the adopted
+ // nomenclature in ProcessInstanceInfo we adopt the d
@@ -70,6 +71,12 @@ struct StatFields {
long unsigned stime;
long cutime;
long cstime;
+ // in proc_pid_stat(5) this field is specified as priority
hawkinsw wrote:
```suggestion
// In proc_pid_stat(5) this field is specified as priority
```
https://gi
@@ -115,13 +124,19 @@ static bool GetStatusInfo(::pid_t Pid,
ProcessInstanceInfo &ProcessInfo,
return ts;
};
+ // priority (nice) values run from 19 to -20 inclusive (in linux). In the
+ // prpsinfo struct pr_nice is a char
hawkinsw wrote:
```suggest
@@ -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,
+ };
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 asse
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.
https://
ZequanWu wrote:
> So this DIE is just a declaration. Shouldn't this code have tried to find a
> non declaration DIE for "std::ios_base"?
Yes, I suppose `SymbolFileDWARF::CompleteType` will try to find the definition
DIE for it before calling `DWARFASTParserClang::CompleteTypeFromDWARF`. If the
ZequanWu wrote:
> 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.
Do you mean that the searching in the type index returns a declaration DIE (but
I expected it to always
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 t
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
https://github.com/ZequanWu created
https://github.com/llvm/llvm-project/pull/91799
Fix the problem:
https://github.com/llvm/llvm-project/pull/90663#issuecomment-2105164917 by
enhancing a double-check for #90663
>From 1f6bf890dbfce07b6ab531597e876ab83cfd1298 Mon Sep 17 00:00:00 2001
From: Zeq
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Zequan Wu (ZequanWu)
Changes
Fix the problem:
https://github.com/llvm/llvm-project/pull/90663#issuecomment-2105164917 by
enhancing a double-check for #90663
---
Full diff: https://github.com/llvm/llvm-project/pull/91799.diff
1 Files Aff
ZequanWu wrote:
I sent an alternative fix at https://github.com/llvm/llvm-project/pull/91799.
> The .debug_names spec states that only entries with definitions should be in
> the .debug_names table...
Do it mean the .debug_names is implemented incorrectly?
https://github.com/llvm/llvm-project
https://github.com/clayborg commented:
Let me verify this works. I would also like this to fix:
```
bool DebugNamesDWARFIndex::ProcessEntry(
const DebugNames::Entry &entry,
llvm::function_ref callback) {
std::optional ref = ToDIERef(entry);
if (!ref)
return true;
SymbolFileDWARF
felipepiovezan wrote:
AFAICT we never added new entries -- definitely not forward declarations -- to
the table when doing the idx_parent work. Either they were already there, or
the entry would have no parent. Would be nice to have an example to see this in
action.
https://github.com/llvm/llv
ZequanWu wrote:
> To the above function to ensure we don't waste any time trying to parse any
> DIE information for forward declaration when using .debug_names. This will
> cause a TON of churn on our DWARF parser and cause us to pull in and parse
> way too much.
That sounds like a better fix
https://github.com/royitaqi updated
https://github.com/llvm/llvm-project/pull/90703
>From 0fd67e2de7e702ce6f7353845454ea7ff9f980d6 Mon Sep 17 00:00:00 2001
From: Roy Shi
Date: Tue, 30 Apr 2024 21:35:49 -0700
Subject: [PATCH 01/12] Add SBCommandInterpreter::GetTranscript()
---
lldb/include/lld
https://github.com/royitaqi updated
https://github.com/llvm/llvm-project/pull/90703
>From 0fd67e2de7e702ce6f7353845454ea7ff9f980d6 Mon Sep 17 00:00:00 2001
From: Roy Shi
Date: Tue, 30 Apr 2024 21:35:49 -0700
Subject: [PATCH 01/13] Add SBCommandInterpreter::GetTranscript()
---
lldb/include/lld
@@ -2044,6 +2052,15 @@ bool CommandInterpreter::HandleCommand(const char
*command_line,
m_transcript_stream << result.GetOutputData();
m_transcript_stream << result.GetErrorData();
+ // Add output and error to the transcript item after splitting lines. In the
+ // futur
https://github.com/royitaqi edited
https://github.com/llvm/llvm-project/pull/90703
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -290,6 +290,31 @@ class StructuredData {
void GetDescription(lldb_private::Stream &s) const override;
+/// Creates an Array of substrings by splitting a string around the
+/// occurrences of a separator character.
+///
+/// \param[in] s
+/// The i
https://github.com/royitaqi edited
https://github.com/llvm/llvm-project/pull/90703
___
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.
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 maili
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
@@ -2343,7 +2343,10 @@ bool DWARFASTParserClang::CompleteTypeFromDWARF(const
DWARFDIE &die,
// clang::ExternalASTSource queries for this type.
m_ast.SetHasExternalStorage(clang_type.GetOpaqueQualType(), false);
- if (!die)
+ ParsedDWARFTypeAttributes attrs(die);
+ bool
@@ -85,3 +86,91 @@ def test_command_output(self):
self.assertEqual(res.GetOutput(), "")
self.assertIsNotNone(res.GetError())
self.assertEqual(res.GetError(), "")
+
+def test_structured_transcript(self):
+"""Test structured transcript generati
https://github.com/ZequanWu updated
https://github.com/llvm/llvm-project/pull/91799
>From 1f6bf890dbfce07b6ab531597e876ab83cfd1298 Mon Sep 17 00:00:00 2001
From: Zequan Wu
Date: Fri, 10 May 2024 16:00:22 -0400
Subject: [PATCH 1/2] [lldb][DWARF] Do not complete type from declaration die.
---
l
Author: Zequan Wu
Date: 2024-05-10T16:39:20-04:00
New Revision: a7eff59f78f08f8ef0487dfe2a136fb311af4fd0
URL:
https://github.com/llvm/llvm-project/commit/a7eff59f78f08f8ef0487dfe2a136fb311af4fd0
DIFF:
https://github.com/llvm/llvm-project/commit/a7eff59f78f08f8ef0487dfe2a136fb311af4fd0.diff
LOG
https://github.com/ZequanWu closed
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/royitaqi closed
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
royitaqi wrote:
Gentle ping. :)
@jim
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
https://github.com/royitaqi reopened
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
https://github.com/clayborg created
https://github.com/llvm/llvm-project/pull/91808
When a .debug_names table has entries that use the DW_IDX_parent attributes, we
can end up with entries in the .debug_names table that are not full
definitions. This is because a class that is foward declared,
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
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Greg Clayton (clayborg)
Changes
When a .debug_names table has entries that use the DW_IDX_parent attributes, we
can end up with entries in the .debug_names table that are not full
definitions. This is because a class that is foward declare
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_parent a
jeffreytan81 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?
https://github.com/llvm/llvm-project/pull/91
felipepiovezan wrote:
we should probably fix the underlying issue instead:
https://github.com/llvm/llvm-project/issues/77696
https://github.com/llvm/llvm-project/pull/91808
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.o
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)`
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; entrie
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 .de
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
@@ -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 (m_opaque_sp
@@ -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 (m_opaque_sp
@@ -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 = nullp
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
__
jasonmolenda wrote:
> I have fixed/worked around the mach exception issue in a [followup
> commit](https://github.com/llvm/llvm-project/commit/b903badd73a2467fdd4e363231f2bf9b0704b546)
> with a `settings set platform.plugin.darwin.ignored-exceptions
> EXC_BAD_INSTRUCTION`. Now the process gets
chelcassanova wrote:
Hm, so in that case should we focus on adding an `SBStream::GetUseColor` so
that the stream's colour settings can take precedence here?
https://github.com/llvm/llvm-project/pull/91404
___
lldb-commits mailing list
lldb-commits@lis
adrian-prantl wrote:
Could this commit have broken the bots?
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake/1897/
https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.
jasonmolenda wrote:
Ah, I misunderstood what the nature of the failure was. I tried running the
shell test, and it's failing for different reasons. I almost never touch shell
tests, I find them really hard to debug so I'm not sure what the problem is.
If I run it by hand,
```
(lldb) settin
jasonmolenda wrote:
maybe the shell test is building without debug info, I am surprised to see
assembly there. If I build it like that and run it by hand,
```
(lldb) settings set platform.plugin.darwin.ignored-exceptions
EXC_BAD_INSTRUCTION
(lldb) b sigill_handler
Breakpoint 1: where = a.out`
https://github.com/adrian-prantl approved this pull request.
https://github.com/llvm/llvm-project/pull/91686
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
ZequanWu wrote:
> Could this commit have broken the bots?
> https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake/1897/
Looks like so, but I cannot repro the test failure locally.
https://github.com/llvm/llvm-project/pull/90663
___
lldb-c
jimingham wrote:
> Hm, so in that case should we focus on adding an `SBStream::GetUseColor` so
> that the stream's colour settings can take precedence here?
That's the only way it makes sense to me. But if we are going to rely on the
stream, we also have to be sure that we're setting the Stre
ZequanWu wrote:
> > Could this commit have broken the bots?
> > https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake/1897/
>
> Looks like so, but I cannot repro the test failure locally.
The error message is different in current latest build
(https://green.lab.llvm.org/job/llvm.or
felipepiovezan 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 a
felipepiovezan wrote:
Ok, minor correction: if there is no complete parent chain, it just defaults to
the older implementation (which calls ProcessEntry). But my point still stands:
I don't believe this is related to the presence of IDX_parent.
```
void DebugNamesDWARFIndex::GetFullyQualifiedT
https://github.com/aaupov edited https://github.com/llvm/llvm-project/pull/91773
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/aaupov closed https://github.com/llvm/llvm-project/pull/91773
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/aaupov edited https://github.com/llvm/llvm-project/pull/91775
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/aaupov closed https://github.com/llvm/llvm-project/pull/91775
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
100 matches
Mail list logo
