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
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/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/91773
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
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
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
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
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
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
___
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
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 =
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)
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
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
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
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)`
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
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/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
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
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
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/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
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 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
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
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
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.
---
@@ -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
@@ -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/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 ) const override;
+/// Creates an Array of substrings by splitting a string around the
+/// occurrences of a separator character.
+///
+/// \param[in] s
+/// The
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
@@ -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
+ //
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()
---
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()
---
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
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/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 =
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?
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
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:
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
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
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
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
@@ -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,
+
@@ -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
```
@@ -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
@@ -115,13 +124,19 @@ static bool GetStatusInfo(::pid_t Pid,
ProcessInstanceInfo ,
return ts;
};
+ // priority (nice) values run from 19 to -20 inclusive (in linux). In the
+ // prpsinfo struct pr_nice is a char
hawkinsw wrote:
```suggestion
//
@@ -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
@@ -115,13 +124,19 @@ static bool GetStatusInfo(::pid_t Pid,
ProcessInstanceInfo ,
return ts;
};
+ // priority (nice) values run from 19 to -20 inclusive (in linux). In the
hawkinsw wrote:
```suggestion
// Priority (nice) values run from 19 to -20
@@ -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;
+
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
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
@@ -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.
@@ -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/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
@@ -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;
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://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
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/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: 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
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
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
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
@@ -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,
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
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://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
@@ -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
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
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
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
@@ -87,8 +105,15 @@ SymbolVendorELF::CreateInstance(const lldb::ModuleSP
_sp,
FileSpecList search_paths = Target::GetDefaultDebugFileSearchPaths();
FileSpec dsym_fspec =
PluginManager::LocateExecutableSymbolFile(module_spec, search_paths);
- if (!dsym_fspec)
-
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
@@ -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
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://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
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
Author: David Spickett
Date: 2024-05-10T09:20:48+01:00
New Revision: a76518cadc5eaa6b6d07334e2b5bc08382aabe49
URL:
https://github.com/llvm/llvm-project/commit/a76518cadc5eaa6b6d07334e2b5bc08382aabe49
DIFF:
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.
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
1 - 100 of 106 matches
Mail list logo
