https://github.com/medismailben approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/95125
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -32,6 +37,39 @@ def check_help_options(self, cmd_name, opt_list, substrs=[]):
print(f"Opt Vec\n{substrs}")
self.expect("help " + cmd_name, substrs=substrs)
+def run_one_repeat(self, commands, expected_num_errors):
+with open(self.stdin_path, "w")
@@ -1827,6 +1838,15 @@ class CommandObjectScriptingObjectParsed : public
CommandObjectParsed {
ScriptedCommandSynchronicity GetSynchronicity() { return m_synchro; }
+ std::optional GetRepeatCommand(Args &args,
+ uint32_t index)
@@ -32,6 +37,39 @@ def check_help_options(self, cmd_name, opt_list, substrs=[]):
print(f"Opt Vec\n{substrs}")
self.expect("help " + cmd_name, substrs=substrs)
+def run_one_repeat(self, commands, expected_num_errors):
+with open(self.stdin_path, "w")
@@ -831,6 +831,29 @@ bool
lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommandObject(
return true;
}
+std::optional
+lldb_private::python::SWIGBridge::LLDBSwigPythonGetRepeatCommandForScriptedCommand(PyObject
*implementor,
+
https://github.com/medismailben approved this pull request.
LGTM with nits
https://github.com/llvm/llvm-project/pull/94823
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/medismailben edited
https://github.com/llvm/llvm-project/pull/94823
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1827,6 +1838,15 @@ class CommandObjectScriptingObjectParsed : public
CommandObjectParsed {
ScriptedCommandSynchronicity GetSynchronicity() { return m_synchro; }
+ std::optional GetRepeatCommand(Args &args,
+ uint32_t index)
vvereschaka wrote:
@clayborg ,
the test is still flaky with these changes on the windows build/target host.
Here are two failed test outputs. They are a bit different.
failure 1:
```
# executed command:
'd:\projects\llvm-project\lldb\build-lldb-win\bin\filecheck.exe'
'D:\projects\llvm-projec
jimingham wrote:
The one thing about this that strikes me as odd is that if you have an SBValue
that doesn't have a Synthetic Value, this will return the non-synthetic value.
Getting the NonSynthetic Value didn't have this problem because there's always
a non-synthetic value, so provided the
kevinfrei wrote:
> What do you mean by "normal" location?
"normal" as defined by whoever wrote Makefile.rules originally and thought that
was the correct place to file tools like ar and objcopy, I guess? So, on your
build machine, do you know where the llvm-dwp file might be installed? Because
petrhosek wrote:
> > @petrhosek Is there a way you can help @kevinfrei validate this on Fuchsia
>
> Specifically, I'm adding tests that require dwp/llvm-dwp laying around
> somewhere, and it looks like Fuchsia doesn't put it in the 'normal' location,
> and I have no idea how to simply disable
https://github.com/kevinfrei updated
https://github.com/llvm/llvm-project/pull/96802
>From 5db458e34f9db981d78bdac0ba18a97d506fb404 Mon Sep 17 00:00:00 2001
From: Kevin Frei
Date: Mon, 25 Mar 2024 08:23:47 -0700
Subject: [PATCH 01/13] Trying to deal with Linux AArch64 test failures :/
---
...
kevinfrei wrote:
> @petrhosek Is there a way you can help @kevinfrei validate this on Fuchsia
Specifically, I'm adding tests that require dwp/llvm-dwp laying around
somewhere, and it looks like Fuchsia doesn't put it in the 'normal' location,
and I have no idea how to simply disable an LLDB te
https://github.com/kevinfrei edited
https://github.com/llvm/llvm-project/pull/96802
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ZequanWu approved this pull request.
https://github.com/llvm/llvm-project/pull/96755
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
dwblaikie wrote:
Oh, this code was touched really recently in
66df6141659375e738d9b9b74bf79b2317576042 (@augusto2112 ) (see notes in previous
comments about how this code should be generalized)
https://github.com/llvm/llvm-project/pull/93809
___
lldb
dwblaikie wrote:
Here's the smallest patch that would put explicit alignment on any packed
structure:
```
diff --git a/clang/lib/CodeGen/CGDebugInfo.cpp
b/clang/lib/CodeGen/CGDebugInfo.cpp
index a072475ba770..bbb13ddd593b 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CG
dwblaikie wrote:
The other effects of `packed` are encoded (the changes to the member offsets)
but that's not the only effect, and we shouldn't use that effect (which isn't
guaranteed to be observable - as in the case of "packed struct with a single
member/that just happens to not have padding
dwblaikie wrote:
oh, slight misquote above - `aligned(1)` is a no-op, as that attribute can't
reduce the alignment...
But I think my argument still stands, roughly as - if increases in alignment
are explicitly specified, decreases in alignment should be too.
https://github.com/llvm/llvm-proj
dwblaikie wrote:
Ah, I think this right solution to /this/ case is that the compiler should be
emitting the alignment for the structure?
Like there's no way for the debugger to know that this structure is
underaligned at the moment:
```
struct __attribute__((packed)) t1 {
int i;
};
```
Which
https://github.com/ZequanWu approved this pull request.
https://github.com/llvm/llvm-project/pull/96751
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Jlalond wrote:
@petrhosek Is there a way you can help @kevinfrei validate this on Fuschia?
https://github.com/llvm/llvm-project/pull/96802
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-co
@@ -1798,6 +1805,13 @@ DWARFASTParserClang::ParseStructureLikeDIE(const
SymbolContext &sc,
}
if (def_die) {
+if (auto [it, inserted] = dwarf->GetDIEToType().try_emplace(
labath wrote:
For uniqueness, yes the unique map should already catch that (thou
@@ -1798,6 +1805,13 @@ DWARFASTParserClang::ParseStructureLikeDIE(const
SymbolContext &sc,
}
if (def_die) {
+if (auto [it, inserted] = dwarf->GetDIEToType().try_emplace(
ZequanWu wrote:
This part seems unnecessary as `UniqueDWARFASTType` map already
@@ -1798,6 +1805,13 @@ DWARFASTParserClang::ParseStructureLikeDIE(const
SymbolContext &sc,
}
if (def_die) {
+if (auto [it, inserted] = dwarf->GetDIEToType().try_emplace(
labath wrote:
It's possible, but I am not sure if it's worth it, as this code wi
https://github.com/kevinfrei created
https://github.com/llvm/llvm-project/pull/96802
This is the same diff I've put up at many times before. I've been trying to add
some brand new functionality to the LLDB test infrastucture, and we all know
that no good deed goes unpunished. The last attempt
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/96800
___
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/96751
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
clayborg wrote:
Here is a PR to fix the flaky test:
https://github.com/llvm/llvm-project/pull/96800
https://github.com/llvm/llvm-project/pull/87740
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listi
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Greg Clayton (clayborg)
Changes
When we check for the "struct CustomType" in the NODWP, we can just make sure
that we have both types showing up, the next tests will validate the types are
correct. Also added a "-DAG" to the integer and fl
https://github.com/clayborg created
https://github.com/llvm/llvm-project/pull/96800
When we check for the "struct CustomType" in the NODWP, we can just make sure
that we have both types showing up, the next tests will validate the types are
correct. Also added a "-DAG" to the integer and float
clayborg wrote:
Sorry for the delay, I am still wondering if we just want to have the value
objects for enums return the text name as the value, and have the summary show
the value as an appropriate integer if the format is eFormatEnum. When you
display registers bitfields do you have a ValueO
dwblaikie wrote:
> It looks like the test is flaky:
> https://lab.llvm.org/buildbot/#/builders/59/builds/535
>
> It looks like the order of the types is nondeterministic. I think you should
> be able to use CHECK-DAG along with [this trick to match
> newlines](https://llvm.org/docs/CommandGui
@@ -1798,6 +1805,13 @@ DWARFASTParserClang::ParseStructureLikeDIE(const
SymbolContext &sc,
}
if (def_die) {
+if (auto [it, inserted] = dwarf->GetDIEToType().try_emplace(
dwblaikie wrote:
any chance of reducing/avoiding this duplication? Looks like th
Jlalond wrote:
@DavidSpickett We'll be fine with 32b size_t. Directories in minidumps have to
all have their offsets be 32b addressable, so if you were to fill the directory
list up to the `size_t` max, it would be a corrupted minidump
https://github.com/llvm/llvm-project/pull/96564
__
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/94794
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -90,17 +90,9 @@ void InstrumentationRuntimeASanLibsanitizers::Activate() {
if (!process_sp)
return;
- lldb::ModuleSP module_sp = GetRuntimeModuleSP();
-
Breakpoint *breakpoint = ReportRetriever::SetupBreakpoint(
- module_sp, process_sp, ConstString("sanitizer
https://github.com/clayborg requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/94794
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Jlalond edited
https://github.com/llvm/llvm-project/pull/96724
___
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/94785
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -287,7 +287,7 @@ Status PlatformAndroid::DownloadModuleSlice(const FileSpec
&src_file_spec,
static constexpr llvm::StringLiteral k_zip_separator("!/");
size_t pos = source_file.find(k_zip_separator);
if (pos != std::string::npos)
-source_file = source_file.substr(
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/94785
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jeffreytan81 wrote:
Thanks for the update! Not sure why but the github notification system seems to
fail me recently which I did not get any update emails from this thread until
proactively checking now.
Sounds good! Let us know the final stack/PR for the delaying forward
declaration is up,
@@ -2192,87 +2097,82 @@ bool DWARFASTParserClang::CompleteRecordType(const
DWARFDIE &die,
ClangASTImporter::LayoutInfo layout_info;
std::vector contained_type_dies;
- if (die.HasChildren()) {
-const bool type_is_objc_object_or_interface =
-TypeSystemClang::Is
@@ -1893,72 +1849,21 @@ DWARFASTParserClang::ParseStructureLikeDIE(const
SymbolContext &sc,
dwarf->GetUniqueDWARFASTTypeMap().Insert(unique_typename,
*unique_ast_entry_up);
- if (!attrs.is_forward_declaration) {
-// Always sta
https://github.com/Michael137 approved this pull request.
This is a really nice cleanup! It actually aligns almost exactly with [our
in-progress version of
this](https://github.com/llvm/llvm-project/blob/caacb57a46f34bf663fa5ab2190b361ce29b255b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParse
github-actions[bot] wrote:
@e-kwsm Congratulations on having your first Pull Request (PR) merged into the
LLVM Project!
Your changes will be combined with recent changes from other authors, then
tested
by our [build bots](https://lab.llvm.org/buildbot/). If there is a problem with
a build,
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/94017
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Eisuke Kawashima
Date: 2024-06-26T15:59:07+01:00
New Revision: 586114510c5fa71d1377c7f53e68a3b12c472aa2
URL:
https://github.com/llvm/llvm-project/commit/586114510c5fa71d1377c7f53e68a3b12c472aa2
DIFF:
https://github.com/llvm/llvm-project/commit/586114510c5fa71d1377c7f53e68a3b12c472aa2.di
@@ -85,13 +85,17 @@ class ScriptedPythonInterface : virtual public
ScriptedInterface {
bool has_class_name = !class_name.empty();
bool has_interpreter_dict =
!(llvm::StringRef(m_interpreter.GetDictionaryName()).empty());
-if (!has_class_name && !has_interpr
github-actions[bot] wrote:
@e-kwsm Congratulations on having your first Pull Request (PR) merged into the
LLVM Project!
Your changes will be combined with recent changes from other authors, then
tested
by our [build bots](https://lab.llvm.org/buildbot/). If there is a problem with
a build,
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/94039
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Eisuke Kawashima
Date: 2024-06-26T15:55:15+01:00
New Revision: fd35a92300a00edaf56ae94176317390677569a4
URL:
https://github.com/llvm/llvm-project/commit/fd35a92300a00edaf56ae94176317390677569a4
DIFF:
https://github.com/llvm/llvm-project/commit/fd35a92300a00edaf56ae94176317390677569a4.di
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/94785
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -287,7 +287,7 @@ Status PlatformAndroid::DownloadModuleSlice(const FileSpec
&src_file_spec,
static constexpr llvm::StringLiteral k_zip_separator("!/");
size_t pos = source_file.find(k_zip_separator);
if (pos != std::string::npos)
-source_file = source_file.substr(
https://github.com/DavidSpickett requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/94785
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
I'm assuming that `Address` keeps track of the value if it changes due to
position independent code, ASLR, etc. between runs. So this seems fine.
Can this be tested? Not sure what coverage we have of these plugins right now.
https://github.com/llvm/llvm-project/pull/9479
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/95768
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/95768
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -4179,21 +4179,124 @@ struct GdbServerTargetInfo {
RegisterSetMap reg_set_map;
};
-static std::vector ParseFlagsFields(XMLNode flags_node,
- unsigned size) {
+static FieldEnum::Enumerators ParseEnumEvalues(const XML
https://github.com/DavidSpickett updated
https://github.com/llvm/llvm-project/pull/95768
>From a9b542a1686be0afd73ad89a504d2c66ba6c4a4f Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Mon, 11 Mar 2024 10:56:29 +
Subject: [PATCH 1/5] [lldb] Parse and display register field enums
This te
@@ -4179,21 +4179,124 @@ struct GdbServerTargetInfo {
RegisterSetMap reg_set_map;
};
-static std::vector ParseFlagsFields(XMLNode flags_node,
- unsigned size) {
+static FieldEnum::Enumerators ParseEnumEvalues(const XML
slydiman wrote:
It seems this patch breaks the following tests on cross setups:
```
Failed Tests (6):
lldb-api :: commands/process/attach/TestProcessAttach.py
lldb-api :: commands/process/detach-resumes/TestDetachResumes.py
lldb-api :: functionalities/dyld-exec-linux/TestDyldExecLinux.py
DavidSpickett wrote:
To be clear, this is not blocking register field enums work anymore. I decided
to push on with that because folks can `register info` to see the values if
they really need them.
Having this would be nice, but there's plenty of time to consider whether it's
worth it.
http
https://github.com/Michael137 commented:
Without having reviewed this in detail yet this I like the goal, thanks for
doing this.
This aligns with what https://github.com/llvm/llvm-project/pull/95100 is trying
to do. There we similarly want to make sure that we start and complete
definitions i
https://github.com/Michael137 approved this pull request.
https://github.com/llvm/llvm-project/pull/96751
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -2192,87 +2097,82 @@ bool DWARFASTParserClang::CompleteRecordType(const
DWARFDIE &die,
ClangASTImporter::LayoutInfo layout_info;
std::vector contained_type_dies;
- if (die.HasChildren()) {
-const bool type_is_objc_object_or_interface =
-TypeSystemClang::Is
@@ -1893,72 +1849,21 @@ DWARFASTParserClang::ParseStructureLikeDIE(const
SymbolContext &sc,
dwarf->GetUniqueDWARFASTTypeMap().Insert(unique_typename,
*unique_ast_entry_up);
- if (!attrs.is_forward_declaration) {
-// Always sta
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Pavel Labath (labath)
Changes
Right now, ParseStructureLikeDIE begins the class definition (which amounts to
parsing the opening "{" of a class and promising to be able to fill it in
later) if it finds a definition DIE.
This makes sense i
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/96755
Right now, ParseStructureLikeDIE begins the class definition (which amounts to
parsing the opening "{" of a class and promising to be able to fill it in
later) if it finds a definition DIE.
This makes sense in t
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Pavel Labath (labath)
Changes
This is a regression from #96484 caught by @ZequanWu.
Note that we will still create separate enum types for types parsed from two
definitions. This is different from how we handle classes, but it is not a
re
@@ -897,32 +895,39 @@ TypeSP DWARFASTParserClang::ParseEnum(const SymbolContext
&sc,
}
CompilerType clang_type = m_ast.CreateEnumerationType(
- attrs.name.GetStringRef(), GetClangDeclContextContainingDIE(die,
nullptr),
- GetOwningClangModule(die), attrs.decl, e
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/96751
This is a regression from #96484 caught by @ZequanWu.
Note that we will still create separate enum types for types parsed from two
definitions. This is different from how we handle classes, but it is not a
regre
Michael137 wrote:
While fixing the libc++ formatters in preparation for the [compressed_pair
change](https://github.com/llvm/llvm-project/issues/93069), i encountered
another issue which I'm not sure entirely how to best reconcile. There's [this
assumption in
`RecordLayoutBuilder`](https://gi
DavidSpickett wrote:
ping!
https://github.com/llvm/llvm-project/pull/90059
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -897,32 +895,39 @@ TypeSP DWARFASTParserClang::ParseEnum(const SymbolContext
&sc,
}
CompilerType clang_type = m_ast.CreateEnumerationType(
- attrs.name.GetStringRef(), GetClangDeclContextContainingDIE(die,
nullptr),
- GetOwningClangModule(die), attrs.decl, e
DavidSpickett wrote:
> The error could then be surfaced back in a meaningful way, like "hey the
> server gave me some bunk data so pretty-printing registers might look weird".
> What do you think?
IIRC GDB will do something like this, though it may just be (paraphrasing) "yo
this XML be weird
labath wrote:
The thread that you care about is stopped at a breakpoint, right?
If so, then you can use the `lldbutil.get_threads_stopped_at_breakpoint`
utility to find it...
https://github.com/llvm/llvm-project/pull/96685
___
lldb-commits mailing lis
labath wrote:
I'm not sure if these names come from the demangler or debug info, but windows
has different implementations for both, so it not surprising they're different.
Assuming we don't care about the precise formatting of the names, we could
just check whether the name of the function i
@@ -97,6 +101,9 @@ def finalize_build_dictionary(dictionary):
dictionary = {}
dictionary["OS"] = "Android"
dictionary["PIE"] = 1
+elif target_is_remote_linux():
labath wrote:
For consistency, I think we should do this for all li
DavidSpickett wrote:
`size_t` will be 32 bit on 32 bit platforms, is this ok given the expected
range of this variable?
I don't see any failures on 32 bit Arm right now but worth asking in case it
causes flaky tests later.
https://github.com/llvm/llvm-project/pull/96564
__
Michael137 wrote:
> I have the whole thing implemented (complete with test cases). If you really
> want to dig through the complete code, you can see it at
> https://github.com/cmtice/llvm-project/tree/DIL-work-new/ (note that I will
> be cleaning up the Parser & Evaluator code before actually
83 matches
Mail list logo
