labath wrote:
One of the problems here is that we actually have two implementations of pdb
readers in lldb (SymbolFilePDB, and SymbolFileNativePDB). PDB is the default
(kind of -- if you are on windows, and cmake manages to find the DIA SDK),
while the majority of users (my non-scientific samp
hokein wrote:
The newly-added test causes a msan failure:
```
==1960==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x55e25271b29e in RetryAfterSignal
llvm-project/llvm/include/llvm/Support/Errno.h:37:11
#1 0x55e25271b29e in lldb_private::NativeFile::Write(void const*, unsigne
Author: Haojian Wu
Date: 2024-08-05T09:37:36+02:00
New Revision: 86f7374078288e2b3d3d0fd66428f7752e2319e6
URL:
https://github.com/llvm/llvm-project/commit/86f7374078288e2b3d3d0fd66428f7752e2319e6
DIFF:
https://github.com/llvm/llvm-project/commit/86f7374078288e2b3d3d0fd66428f7752e2319e6.diff
LO
https://github.com/medismailben created
https://github.com/llvm/llvm-project/pull/101929
This patch loosen the parsing requirement to allow parsing not only JSON
dictionaries but also JSON arrays.
>From 54081f56181d954365f9ab762ca6715e28119ad4 Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani
@@ -86,7 +86,11 @@ lldb::SBError SBStructuredData::SetFromJSON(lldb::SBStream
&stream) {
StructuredData::ParseJSON(stream.GetData());
m_impl_up->SetObjectSP(json_obj);
- if (!json_obj || json_obj->GetType() != eStructuredDataTypeDictionary)
+ static constexpr Struct
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Med Ismail Bennani (medismailben)
Changes
This patch loosen the parsing requirement to allow parsing not only JSON
dictionaries but also JSON arrays.
---
Full diff: https://github.com/llvm/llvm-project/pull/101929.diff
2 Files Affected:
hokein wrote:
@Jlalond, I revert it in 86f7374078288e2b3d3d0fd66428f7752e2319e6 to keep the
trunk green. Feel free to reland the patch with the fix.
https://github.com/llvm/llvm-project/pull/101770
___
lldb-commits mailing list
lldb-commits@lists.llvm
https://github.com/medismailben updated
https://github.com/llvm/llvm-project/pull/99814
>From 54081f56181d954365f9ab762ca6715e28119ad4 Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani
Date: Mon, 5 Aug 2024 00:37:51 -0700
Subject: [PATCH 1/2] [lldb/API] Fix SBStructuredData JSON Array parsing
github-actions[bot] wrote:
:warning: Python code formatter, darker found issues in your code. :warning:
You can test this locally with the following command:
``bash
darker --check --diff -r
8d1b17b6623742ec4454f5bae2e23f8b30124314...54081f56181d954365f9ab762ca6715e28119ad4
lldb/
https://github.com/medismailben updated
https://github.com/llvm/llvm-project/pull/101929
>From 18159bbcf6418d18ceb2a77e464e98e349225c1c Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani
Date: Mon, 5 Aug 2024 00:48:58 -0700
Subject: [PATCH] [lldb/API] Fix SBStructuredData JSON Array parsing
Thi
https://github.com/medismailben updated
https://github.com/llvm/llvm-project/pull/99814
>From 4b8ccab40914a9a6ee32939911b66fb701605c96 Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani
Date: Mon, 5 Aug 2024 00:49:55 -0700
Subject: [PATCH 1/2] [lldb/API] Fix SBStructuredData JSON Array parsing
https://github.com/medismailben updated
https://github.com/llvm/llvm-project/pull/99814
>From 4b8ccab40914a9a6ee32939911b66fb701605c96 Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani
Date: Mon, 5 Aug 2024 00:49:55 -0700
Subject: [PATCH 1/2] [lldb/API] Fix SBStructuredData JSON Array parsing
https://github.com/medismailben created
https://github.com/llvm/llvm-project/pull/101931
Following 9a9ec228cdcf, since the ThreadPlanPython class started making use of
the Scripted Interface instead of calling directly into the python methods,
this class can work with other scripting languages
https://github.com/labath commented:
> Looks good to me. @labath should give this another look as the biggest
> skeptic here :)
My position remains unchanged. I don't think we should have this functionality.
I'm not going to block you adding it either..
https://github.com/llvm/llvm-project/p
@@ -165,6 +235,14 @@ def use_support_substitutions(config):
if config.cmake_sysroot:
host_flags += ["--sysroot={}".format(config.cmake_sysroot)]
+if config.enable_remote and config.has_libcxx:
+host_flags += [
+"-L{}".format(config.libcxx_li
https://github.com/labath edited https://github.com/llvm/llvm-project/pull/95986
___
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: Med Ismail Bennani (medismailben)
Changes
Following 9a9ec228cdcf, since the ThreadPlanPython class started making use of
the Scripted Interface instead of calling directly into the python methods,
this class can work with other scripting l
labath wrote:
> Out of curiosity, what's stopping us from using `lld` on Windows?
It's not the default configuration of clang -- anywhere. The difference is that
on linux/elf, the choice of linker has very little impact on the debug info.
https://github.com/llvm/llvm-project/pull/100710
__
https://github.com/Michael137 ready_for_review
https://github.com/llvm/llvm-project/pull/101778
___
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: Michael Buch (Michael137)
Changes
This patch addresses an issue that will arise with future SDKs. The
ClangExpressionParser currently unconditionally sets
`-fbuiltin-headers-in-system-modules` when evaluating expressions with the
`target.
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/101778
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/medismailben created
https://github.com/llvm/llvm-project/pull/101934
This patch is a follow-up to #97263 that fix ambigous abbreviated command
resolution.
When multiple commands are resolved, instead of failing to pick a command to
run, this patch changes to resolution log
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Med Ismail Bennani (medismailben)
Changes
This patch is a follow-up to #97263 that fix ambigous abbreviated
command resolution.
When multiple commands are resolved, instead of failing to pick a command to
run, this patch changes to resolu
https://github.com/medismailben created
https://github.com/llvm/llvm-project/pull/101935
This patch renames the `scripting template` subcommand to be `scripting
extension` instead since that would make more sense for upcoming commands.
>From e398844b5482d097250f0f8b96adf23e548f2927 Mon Sep 17
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Med Ismail Bennani (medismailben)
Changes
This patch renames the `scripting template` subcommand to be `scripting
extension` instead since that would make more sense for upcoming commands.
---
Full diff: https://github.com/llvm/llvm-projec
https://github.com/DavidSpickett approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/101929
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
This is for this sort of lookup:
```
(lldb) reg read pc
```
Right? As opposed to tab completion.
This needs a test case or at least a clear example as a comment in the code if
a test is not possible. It seems fine from how you've described it but these
things come across b
https://github.com/DavidSpickett approved this pull request.
So the things listed are "scripting extensions" and then there are templates to
get started using those extensions. Makes sense to me.
https://github.com/llvm/llvm-project/pull/101935
___
ll
https://github.com/labath commented:
Better, but I still have some comments on the implementation. I see you ended
up not using the fallible_iterator thing in the end. I'm sort of ok with that,
though I think it'd be better to do it that way, as we wouldn't need the
upfront array bounds check
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/101272
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -136,6 +136,22 @@ static size_t layout(BlobAllocator &File,
MinidumpYAML::ExceptionStream &S) {
return DataEnd;
}
+static size_t layout(BlobAllocator &File, MinidumpYAML::Memory64ListStream &S)
{
+ size_t BaseRVA = File.tell() + sizeof(minidump::Memory64ListHeader);
--
@@ -132,6 +140,71 @@ class MinidumpFile : public Binary {
size_t Stride;
};
+ class Memory64ListFacade {
labath wrote:
I don't think you need this facade class (particularly if we can avoid storing
the of the vector thing). llvm APIs of this kind will
@@ -373,7 +373,6 @@ void yaml::MappingContextTraits::mapping(
void yaml::MappingContextTraits::mapping(
IO &IO, MemoryDescriptor_64 &Memory, BinaryRef &Content) {
mapRequiredHex(IO, "Start of Memory Range", Memory.StartOfMemoryRange);
- mapRequiredHex(IO, "Data Size", Me
@@ -152,21 +225,21 @@ class MinidumpFile : public Binary {
}
/// Return a slice of the given data array, with bounds checking.
- static Expected> getDataSlice(ArrayRef Data,
- size_t Offset, size_t Size);
+ static Expected
@@ -132,6 +140,71 @@ class MinidumpFile : public Binary {
size_t Stride;
};
+ class Memory64ListFacade {
+struct Memory64Iterator {
+public:
+ Memory64Iterator(size_t Count, uint64_t BaseRVA,
+ const Memory64ListFacade *Parent)
+
@@ -336,3 +336,52 @@ TEST(MinidumpYAML, ExceptionStream_ExtraParameter) {
0xab, 0xad, 0xca, 0xfe}),
*ExpectedContext);
}
+
+TEST(MinidumpYAML, MemoryRegion_64bit) {
+ SmallString<0> Storage;
+ auto ExpectedFile = toBinary(Storage, R"
@@ -132,6 +140,71 @@ class MinidumpFile : public Binary {
size_t Stride;
};
+ class Memory64ListFacade {
+struct Memory64Iterator {
+public:
+ Memory64Iterator(size_t Count, uint64_t BaseRVA,
+ const Memory64ListFacade *Parent)
+
@@ -11,6 +11,7 @@
#include "llvm/ADT/DenseMap.h"
#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/fallible_iterator.h"
labath wrote:
You don't actually use this in the current implementation, right?
https://github.com/llvm/llvm-project/pull/101272
labath wrote:
> > Looks good to me. @labath should give this another look as the biggest
> > skeptic here :)
>
> My position remains unchanged. I don't think we should have this
> functionality. I'm not going to block you adding it either..
I was going to leave it at that, but seeing
https:/
labath wrote:
> I don't know what I'm going to do here, and besides armv7 this same problem
> will occur for a target that has no instruction-step primitive. Another
> common trick is to have enough instruction emulation that you can tell what
> instruction will execute next by decoding the cu
Michael137 wrote:
FYI, this is failing on x86 and matrix macOS bots:
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake/4544/execution/node/97/log/?consoleFull
```
FAIL: LLDB
(/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/bin/clang-x86_64)
:: test_abort_with_re
@@ -1302,6 +1298,36 @@ CommandObject *CommandInterpreter::GetUserCommandObject(
return {};
}
+CommandObject *CommandInterpreter::GetAliasCommandObject(
+llvm::StringRef cmd, StringList *matches, StringList *descriptions) const {
+ std::string cmd_str(cmd);
+ auto find_
@@ -1302,6 +1298,36 @@ CommandObject *CommandInterpreter::GetUserCommandObject(
return {};
}
+CommandObject *CommandInterpreter::GetAliasCommandObject(
+llvm::StringRef cmd, StringList *matches, StringList *descriptions) const {
+ std::string cmd_str(cmd);
+ auto find_
@@ -1302,6 +1298,36 @@ CommandObject *CommandInterpreter::GetUserCommandObject(
return {};
}
+CommandObject *CommandInterpreter::GetAliasCommandObject(
+llvm::StringRef cmd, StringList *matches, StringList *descriptions) const {
+ std::string cmd_str(cmd);
+ auto find_
@@ -1302,6 +1298,36 @@ CommandObject *CommandInterpreter::GetUserCommandObject(
return {};
}
+CommandObject *CommandInterpreter::GetAliasCommandObject(
+llvm::StringRef cmd, StringList *matches, StringList *descriptions) const {
+ std::string cmd_str(cmd);
+ auto find_
DavidSpickett wrote:
I'll apply this PR locally and see what I get.
https://github.com/llvm/llvm-project/pull/96260
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath commented:
Thanks for doing this. Unsurprisingly, I have inline comments :)
https://github.com/llvm/llvm-project/pull/101383
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/list
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/101383
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -44,8 +42,70 @@ TEST_F(PipeTest, OpenAsReader) {
size_t name_len = name.size();
name += "foobar";
llvm::StringRef name_ref(name.data(), name_len);
+ // Note OpenAsReader() do nothing on Windows, the pipe is already opened for
+ // read and write.
ASSERT_THAT_ERROR
@@ -44,8 +42,70 @@ TEST_F(PipeTest, OpenAsReader) {
size_t name_len = name.size();
name += "foobar";
llvm::StringRef name_ref(name.data(), name_len);
+ // Note OpenAsReader() do nothing on Windows, the pipe is already opened for
labath wrote:
Let's keep
@@ -105,12 +90,19 @@ Status PipeWindows::CreateNew(llvm::StringRef name,
std::string pipe_path = g_pipe_name_prefix.str();
pipe_path.append(name.str());
+ SECURITY_ATTRIBUTES sa{sizeof(SECURITY_ATTRIBUTES), 0,
+ child_process_inherit ? TRUE : FALSE
@@ -44,8 +42,70 @@ TEST_F(PipeTest, OpenAsReader) {
size_t name_len = name.size();
name += "foobar";
llvm::StringRef name_ref(name.data(), name_len);
+ // Note OpenAsReader() do nothing on Windows, the pipe is already opened for
+ // read and write.
ASSERT_THAT_ERROR
@@ -44,8 +42,70 @@ TEST_F(PipeTest, OpenAsReader) {
size_t name_len = name.size();
name += "foobar";
llvm::StringRef name_ref(name.data(), name_len);
+ // Note OpenAsReader() do nothing on Windows, the pipe is already opened for
+ // read and write.
ASSERT_THAT_ERROR
@@ -44,8 +42,70 @@ TEST_F(PipeTest, OpenAsReader) {
size_t name_len = name.size();
name += "foobar";
llvm::StringRef name_ref(name.data(), name_len);
+ // Note OpenAsReader() do nothing on Windows, the pipe is already opened for
+ // read and write.
ASSERT_THAT_ERROR
@@ -0,0 +1,108 @@
+"""
+Test python scripted platform in lldb
+"""
+
+import os, shutil
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+from lldbsuite.test import lldbtest
+
+
+class ScriptedPlatf
@@ -1003,6 +1010,21 @@ class Platform : public PluginInterface {
FileSpec GetModuleCacheRoot();
};
+class PlatformMetadata {
+public:
+ PlatformMetadata(Debugger &debugger, const ScriptedMetadata metadata);
+ ~PlatformMetadata() = default;
+
+ Debugger &GetDebugger() cons
@@ -180,7 +184,19 @@ class CommandObjectPlatformSelect : public
CommandObjectParsed {
m_interpreter, ArchSpec(), select, error, platform_arch));
if (platform_sp) {
GetDebugger().GetPlatformList().SetSelectedPlatform(platform_sp);
-
+ Opti
@@ -110,6 +110,23 @@ class MyRandomClass:
self.assertTrue(my_random_class)
self.assertEqual(my_random_class.payload, MyRandomClass.payload)
+example_arr = [1, 2.3, "4", {"5": False}]
+arr_str = json.dumps(example_arr)
+s.Clear()
+
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/101929
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath commented:
How is the operator bool change related to this change? AFAICT, the pimpl
pointer should always be valid.
https://github.com/llvm/llvm-project/pull/101929
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
h
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/101929
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
> I'll apply this PR locally and see what I get.
I think that would be definitely appreciated, but I'll just note that this
isn't necessary to answer my question, since the patch doesn't contain any
changes to lldb-server. (My question basically was: what is the stop-reply
packe
@@ -44,8 +42,70 @@ TEST_F(PipeTest, OpenAsReader) {
size_t name_len = name.size();
name += "foobar";
llvm::StringRef name_ref(name.data(), name_len);
+ // Note OpenAsReader() do nothing on Windows, the pipe is already opened for
+ // read and write.
ASSERT_THAT_ERROR
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/3] [lldb] Refactor TypeQuery::ContextMatches, take 2
This is an
@@ -153,19 +127,36 @@ 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);
+
@@ -153,19 +127,36 @@ 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);
+
labath wrote:
> Just applied this patch to the Swift plugin and the tests passed without much
> additional work.
>
> I just had to add a `SetIgnoreModules` API. We don't necessarily have to have
> that upstream. But it would be nice.
I can add that here. Thanks for checking it out.
https://
@@ -44,8 +42,70 @@ TEST_F(PipeTest, OpenAsReader) {
size_t name_len = name.size();
name += "foobar";
llvm::StringRef name_ref(name.data(), name_len);
+ // Note OpenAsReader() do nothing on Windows, the pipe is already opened for
+ // read and write.
ASSERT_THAT_ERROR
labath wrote:
> @labath
>
> > This is where I'll have to disagree with you. The exec following the fork
> > is not "redundant" on linux. A naked fork is an extremely dangerous thing
> > in todays (multithreaded) applications. I'm absolutely certain that the
> > improper use of fork with threa
https://github.com/slydiman updated
https://github.com/llvm/llvm-project/pull/101383
>From 14a653c244ea36233de288ebe67a9f42adaacfc5 Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev
Date: Wed, 31 Jul 2024 22:02:53 +0400
Subject: [PATCH 1/2] [lldb] Added Pipe::WriteWithTimeout()
Fixed few bugs in
slydiman wrote:
@labath Thanks for the review. I have updated everything.
https://github.com/llvm/llvm-project/pull/101383
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/101383
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -47,5 +50,92 @@ TEST_F(PipeTest, OpenAsReader) {
ASSERT_THAT_ERROR(
pipe.OpenAsReader(name_ref, /*child_process_inherit=*/false).ToError(),
llvm::Succeeded());
+
+ ASSERT_TRUE(pipe.CanRead());
}
#endif
+
+TEST_F(PipeTest, WriteWithTimeout) {
+ Pipe pipe;
+
@@ -47,5 +50,92 @@ TEST_F(PipeTest, OpenAsReader) {
ASSERT_THAT_ERROR(
pipe.OpenAsReader(name_ref, /*child_process_inherit=*/false).ToError(),
llvm::Succeeded());
+
+ ASSERT_TRUE(pipe.CanRead());
}
#endif
+
+TEST_F(PipeTest, WriteWithTimeout) {
+ Pipe pipe;
+
https://github.com/labath approved this pull request.
Thanks. Looks good, just a couple of random improvements.
https://github.com/llvm/llvm-project/pull/101383
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
@@ -47,5 +50,92 @@ TEST_F(PipeTest, OpenAsReader) {
ASSERT_THAT_ERROR(
pipe.OpenAsReader(name_ref, /*child_process_inherit=*/false).ToError(),
llvm::Succeeded());
+
+ ASSERT_TRUE(pipe.CanRead());
}
#endif
+
+TEST_F(PipeTest, WriteWithTimeout) {
+ Pipe pipe;
+
@@ -47,5 +50,92 @@ TEST_F(PipeTest, OpenAsReader) {
ASSERT_THAT_ERROR(
pipe.OpenAsReader(name_ref, /*child_process_inherit=*/false).ToError(),
llvm::Succeeded());
+
+ ASSERT_TRUE(pipe.CanRead());
}
#endif
+
+TEST_F(PipeTest, WriteWithTimeout) {
+ Pipe pipe;
+
@@ -47,5 +50,92 @@ TEST_F(PipeTest, OpenAsReader) {
ASSERT_THAT_ERROR(
pipe.OpenAsReader(name_ref, /*child_process_inherit=*/false).ToError(),
llvm::Succeeded());
+
+ ASSERT_TRUE(pipe.CanRead());
}
#endif
+
+TEST_F(PipeTest, WriteWithTimeout) {
+ Pipe pipe;
+
@@ -47,5 +50,92 @@ TEST_F(PipeTest, OpenAsReader) {
ASSERT_THAT_ERROR(
pipe.OpenAsReader(name_ref, /*child_process_inherit=*/false).ToError(),
llvm::Succeeded());
+
+ ASSERT_TRUE(pipe.CanRead());
}
#endif
+
+TEST_F(PipeTest, WriteWithTimeout) {
+ Pipe pipe;
+
@@ -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 .d
https://github.com/sedymrak created
https://github.com/llvm/llvm-project/pull/101981
StepScope enum is a type whose values are passed around, but they are
ultimately ignored.
>From 8abb0771e646dfc46d832f03485b288a4be08168 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Matej=20Ko=C5=A1=C3=ADk?=
Date
github-actions[bot] wrote:
Thank you for submitting a Pull Request (PR) to the LLVM Project!
This PR will be automatically labeled and the relevant teams will be
notified.
If you wish to, you can add reviewers by using the "Reviewers" section on this
page.
If this is not working for you, it
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: None (sedymrak)
Changes
StepScope enum is a type whose values are passed around, but they are
ultimately ignored.
---
Full diff: https://github.com/llvm/llvm-project/pull/101981.diff
1 Files Affected:
- (modified) lldb/source/Commands/C
@@ -2550,6 +2550,21 @@ ModuleSP Process::ReadModuleFromMemory(const FileSpec
&file_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.
+ size_t
slydiman wrote:
@labath
>That's nice, but I think we should figure out how to reduce the number of
>ifdefs in this patch. Porting linux away from fork may not be your concern,
>but figuring out how to make the code less branchy is. If you can do that
>without removing forks, I can take it upo
https://github.com/slydiman updated
https://github.com/llvm/llvm-project/pull/101383
>From 14a653c244ea36233de288ebe67a9f42adaacfc5 Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev
Date: Wed, 31 Jul 2024 22:02:53 +0400
Subject: [PATCH 1/3] [lldb] Added Pipe::WriteWithTimeout()
Fixed few bugs in
DavidSpickett wrote:
I reduced
`lldb/test/API/functionalities/breakpoint/step_over_breakpoint/TestStepOverBreakpoint.py`
a bit to the point where it stalls, which is when it tries to step over from
breakpoint 2 to 3 in `test_step_over`:
```
int b = func(); // breakpoint_2
a = b + func(
@@ -0,0 +1,58 @@
+// REQUIRES: system-linux, native
labath wrote:
If it was a lot of work then sure, I'd agree with you -- but I don't think
that's the case here. I just gave it a shot, and this is the only change I
needed to make on top of your patch to be abl
@@ -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,
@@ -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,
@@ -384,6 +392,9 @@ class ObjectFileELF : public lldb_private::ObjectFile {
/// ELF dependent module dump routine.
void DumpDependentModules(lldb_private::Stream *s);
+ /// ELF dump the .dynamic section
+ void DumpELFDynamic(lldb_private::Stream *s);
lab
@@ -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,
Author: Pavel Labath
Date: 2024-08-05T17:06:07+02:00
New Revision: 212950fbcec3b71fa15ee49e0539333a30159c32
URL:
https://github.com/llvm/llvm-project/commit/212950fbcec3b71fa15ee49e0539333a30159c32
DIFF:
https://github.com/llvm/llvm-project/commit/212950fbcec3b71fa15ee49e0539333a30159c32.diff
https://github.com/labath closed
https://github.com/llvm/llvm-project/pull/101333
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -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 DW
https://github.com/labath closed https://github.com/llvm/llvm-project/pull/99305
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
Superseeded by #101333
https://github.com/llvm/llvm-project/pull/99305
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
bolshakov-a wrote:
When instantiating such an alias:
```cpp
template
using Identity = T;
```
before the patch:
```
TemplateSpecializationType 0x676f0a60 'Identity' sugar alias
|-name: 'Identity' qualified
| `-TypeAliasTemplateDecl 0x676c91d8 Identity
|-TemplateArgument type 'IndirectCla
mizvekov wrote:
> @mizvekov, do you have any idea how to get back the lost
> `SubstTemplateTypeParmType`? It plays an important role in the IWYU tool
> analysis. Thanks!
So from my undertstanding, IWYU only needs the SubstTemplateTypeParmType for
resugaring purposes, in order to recover the t
https://github.com/jimingham approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/101935
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
1 - 100 of 154 matches
Mail list logo
