llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `openmp-s390x-linux`
running on `systemz-1` while building `clang,lldb,llvm` at step 6 "test-openmp".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/88/builds/3573
Here is the relevant piece of the bu
@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
substrs=["registers were unavailable"],
)
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing
@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
substrs=["registers were unavailable"],
)
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing
@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
substrs=["registers were unavailable"],
)
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing
@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
substrs=["registers were unavailable"],
)
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing
@@ -0,0 +1,84 @@
+//===-- RegisterContextPOSIXCore_loongarch64.cpp
--===//
SixWeining wrote:
Generally one line has 80 characters at most.
https://github.com/llvm/llvm-project/pull/112296
_
DavidSpickett wrote:
What you describe makes some sense, but could you give an example of where this
is used?
Can this be triggered with `lldb program file --`? If so
it would be good to 1. put that in the commit message in case anyone hits the
same problem and searches the log, and 2. add a
https://github.com/lawn123 updated
https://github.com/llvm/llvm-project/pull/112296
>From ba485de763a08f6ff3c7468c1a1bfbbfb25ac48f Mon Sep 17 00:00:00 2001
From: Liu An
Date: Tue, 15 Oct 2024 10:31:35 +0800
Subject: [PATCH 1/2] [LoongArch64]: Add support for LoongArch64 in elf-core
for lldb
-
https://github.com/labath commented:
I think this is one of those tests that should really be an API test. As far as
I can tell, there's nothing darwin-specific about this bug -- except for the
fact that building shared libraries in a cross-platform manner is hard. But the
API tests have wrapp
DavidSpickett wrote:
> @DavidSpickett General debugging commands can be used on LoongArch with some
> known issues to be addressed. Here is a summary
> https://github.com/llvm/llvm-project/issues/109394.
For RISC-V I have been using https://github.com/llvm/llvm-project/issues/55383
as the tra
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 7215d5068d96255d487c06d67ae60ba0c04dd08a
2cce5e77082965f6ef2ab71cfd3aea7d45e953b7 --e
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
7215d5068d96255d487c06d67ae60ba0c04dd08a...2cce5e77082965f6ef2ab71cfd3aea7d45e953b7
lldb/
DavidSpickett wrote:
You may be able to reduce the file by changing the `/proc/pid/coredump_filter`
value: https://man7.org/linux/man-pages/man5/core.5.html
I can't say I understand them all but usually what I do is cut things until the
test fails. I've been
https://github.com/lawn123 updated
https://github.com/llvm/llvm-project/pull/112296
>From ba485de763a08f6ff3c7468c1a1bfbbfb25ac48f Mon Sep 17 00:00:00 2001
From: Liu An
Date: Tue, 15 Oct 2024 10:31:35 +0800
Subject: [PATCH 1/3] [LoongArch64]: Add support for LoongArch64 in elf-core
for lldb
-
@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
substrs=["registers were unavailable"],
)
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing
@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
substrs=["registers were unavailable"],
)
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing
@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
substrs=["registers were unavailable"],
)
+@skipIfLLVMTargetMissing("LoongArch")
DavidSpickett wrote:
Is LoongArch one LLVM target or do you need to specifically have LoongArc
@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
substrs=["registers were unavailable"],
)
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing
@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
substrs=["registers were unavailable"],
)
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing
lawn123 wrote:
> I don't see any tests yet, I think
> `lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py` will be
> the place for those. There is a template program file you can use in that
> folder.
@DavidSpickett @SixWeining I have added two test cases to `TestLinuxCore. py
SixWeining wrote:
> I'm not aware of the current status of LoongArch in LLDB
@DavidSpickett General debugging commands can be used on LoongArch with some
known issues to be addressed. Here is a summary #109394.
For this PR, I have checked locally. I can confirm core dump file could be
debugge
https://github.com/DhruvSrivastavaX updated
https://github.com/llvm/llvm-project/pull/111814
>From 08c9d5ae66ca857d165dc878ebd1b2e0de364a24 Mon Sep 17 00:00:00 2001
From: Dhruv-Srivastava
Date: Thu, 10 Oct 2024 02:24:42 -0500
Subject: [PATCH 1/4] Taking base file structure from ELF as reference
@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
substrs=["registers were unavailable"],
)
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing
Author: David Spickett
Date: 2024-10-17T12:48:03+01:00
New Revision: 2882bb192b07674bc11fd5ddd5a4fa6cea194628
URL:
https://github.com/llvm/llvm-project/commit/2882bb192b07674bc11fd5ddd5a4fa6cea194628
DIFF:
https://github.com/llvm/llvm-project/commit/2882bb192b07674bc11fd5ddd5a4fa6cea194628.diff
Michael137 wrote:
> I think this is one of those tests that should really be an API test. As far
> as I can tell, there's nothing darwin-specific about this bug -- except for
> the fact that building shared libraries in a cross-platform manner is hard.
> But the API tests have wrappers that le
Author: Benjamin Kramer
Date: 2024-10-17T13:15:05+02:00
New Revision: 9c80eb7c83c6471d4126ef46f85bf673787de521
URL:
https://github.com/llvm/llvm-project/commit/9c80eb7c83c6471d4126ef46f85bf673787de521
DIFF:
https://github.com/llvm/llvm-project/commit/9c80eb7c83c6471d4126ef46f85bf673787de521.dif
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff f93258e4aca518cba3d48db59ed6143ca19ca99b
3471f167a8376432571ac17643ed3795a459f017 --e
https://github.com/lawn123 updated
https://github.com/llvm/llvm-project/pull/112296
>From ba485de763a08f6ff3c7468c1a1bfbbfb25ac48f Mon Sep 17 00:00:00 2001
From: Liu An
Date: Tue, 15 Oct 2024 10:31:35 +0800
Subject: [PATCH 1/4] [LoongArch64]: Add support for LoongArch64 in elf-core
for lldb
-
@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
substrs=["registers were unavailable"],
)
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing
@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
substrs=["registers were unavailable"],
)
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing
@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
substrs=["registers were unavailable"],
)
+@skipIfLLVMTargetMissing("LoongArch")
lawn123 wrote:
> Is LoongArch one LLVM target or do you need to specifically have LoongArch64
@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
substrs=["registers were unavailable"],
)
+@skipIfLLVMTargetMissing("LoongArch")
lawn123 wrote:
> Is LoongArch one LLVM target or do you need to specifically have LoongArch64
@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
substrs=["registers were unavailable"],
)
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing
@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
substrs=["registers were unavailable"],
)
+@skipIfLLVMTargetMissing("LoongArch")
lawn123 wrote:
> Is LoongArch one LLVM target or do you need to specifically have LoongArch64
@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
substrs=["registers were unavailable"],
)
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing
@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
substrs=["registers were unavailable"],
)
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing
@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
substrs=["registers were unavailable"],
)
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing
lawn123 wrote:
> You may be able to reduce the file by changing the
> `/proc/pid/coredump_filter` value:
> https://man7.org/linux/man-pages/man5/core.5.html
I reduced the core file size to 36kb.
https://github.com/llvm/llvm-project/pull/112296
__
https://github.com/mgorny approved this pull request.
I guess LGTM but I haven't given it really deep thought.
https://github.com/llvm/llvm-project/pull/112565
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mai
SixWeining wrote:
> For RISC-V I have been using #55383 as the tracking issue for overall
> support. If you want to, you could open a similar issue and write out what
> currently works, and I'll link to it from the [main lldb
> page](https://lldb.llvm.org/#platform-support). Not a requirement,
@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
substrs=["registers were unavailable"],
)
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing
https://github.com/DhruvSrivastavaX updated
https://github.com/llvm/llvm-project/pull/111814
>From 08c9d5ae66ca857d165dc878ebd1b2e0de364a24 Mon Sep 17 00:00:00 2001
From: Dhruv-Srivastava
Date: Thu, 10 Oct 2024 02:24:42 -0500
Subject: [PATCH 1/5] Taking base file structure from ELF as reference
DhruvSrivastavaX wrote:
Hi @labath ,
I have dropped some base structure and yaml test cases for the ObjectFileXCOFF
support.
Please provide your comments.
https://github.com/llvm/llvm-project/pull/111814
___
lldb-commits mailing list
lldb-commits@l
@@ -3895,3 +3924,103 @@ std::optional
ObjectFileELF::GetDynamicData() {
}
return std::nullopt;
}
+
+
+std::optional
+ObjectFileELF::GetDynsymDataFromDynamic(uint32_t &num_symbols) {
+ // Every ELF file which represents an executable or shared library has
+ // mandatory .
@@ -3895,3 +3924,103 @@ std::optional
ObjectFileELF::GetDynamicData() {
}
return std::nullopt;
}
+
+
+std::optional
+ObjectFileELF::GetDynsymDataFromDynamic(uint32_t &num_symbols) {
+ // Every ELF file which represents an executable or shared library has
+ // mandatory .
@@ -3895,3 +3924,103 @@ std::optional
ObjectFileELF::GetDynamicData() {
}
return std::nullopt;
}
+
+
+std::optional
+ObjectFileELF::GetDynsymDataFromDynamic(uint32_t &num_symbols) {
+ // Every ELF file which represents an executable or shared library has
+ // mandatory .
@@ -0,0 +1,631 @@
+## This test verifies that loading an ELF file that has no section headers can
+## load the dynamic symbol table using the DT_SYMTAB, DT_SYMENT, DT_HASH or
+## the DT_GNU_HASH .dynamic key/value pairs that are loaded via the PT_DYNAMIC
+## segment.
+##
+## This
@@ -44,6 +44,8 @@
#include "llvm/Support/MathExtras.h"
#include "llvm/Support/MemoryBuffer.h"
#include "llvm/Support/MipsABIFlags.h"
+#include "lldb/Target/Process.h"
+
labath wrote:
btw, this grouping of include blocks with empty lines is an lldb-ism (other
@@ -3895,3 +3924,103 @@ std::optional
ObjectFileELF::GetDynamicData() {
}
return std::nullopt;
}
+
+
+std::optional
+ObjectFileELF::GetDynsymDataFromDynamic(uint32_t &num_symbols) {
+ // Every ELF file which represents an executable or shared library has
+ // mandatory .
ldrumm wrote:
I've let this patch stew for long enough, and I think it's now time. The
spurious test failures in files unchanged by this patch have gone away. After
re-reading the discussion above I'm ready to merge these changes.
There's been a good discussion, which helped me polish this a f
https://github.com/ldrumm closed https://github.com/llvm/llvm-project/pull/86318
___
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/112582
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/labath commented:
If you can't reproduce this, I can take a look, but I think the failures are
likely due to the string length problems.
https://github.com/llvm/llvm-project/pull/112582
___
lldb-commits mailing list
lldb-commits@lis
@@ -76,6 +76,46 @@ using namespace lldb_private::line_editor;
#endif // #if LLDB_EDITLINE_USE_WCHAR
+#if LLDB_EDITLINE_USE_WCHAR
+std::string ToBytes(const std::wstring &in) {
+ static std::locale locale("C.UTF-8");
+ static const auto &cvt =
+ std::use_facet>(locale);
@@ -76,6 +76,46 @@ using namespace lldb_private::line_editor;
#endif // #if LLDB_EDITLINE_USE_WCHAR
+#if LLDB_EDITLINE_USE_WCHAR
+std::string ToBytes(const std::wstring &in) {
+ static std::locale locale("C.UTF-8");
+ static const auto &cvt =
+ std::use_facet>(locale);
@@ -76,6 +76,46 @@ using namespace lldb_private::line_editor;
#endif // #if LLDB_EDITLINE_USE_WCHAR
+#if LLDB_EDITLINE_USE_WCHAR
+std::string ToBytes(const std::wstring &in) {
+ static std::locale locale("C.UTF-8");
+ static const auto &cvt =
+ std::use_facet>(locale);
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/112582
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
DavidSpickett wrote:
Not sure what's going on with the register formatting. It might be that because
we do a substring comparison, `foo = 0x00` is found in `foo = 0x`.
So I would recommend loading the core file manually and just copying whatever
`register read` shows. If the formatting
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/112446
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -363,6 +363,14 @@ class Language : public PluginInterface {
return false;
}
+ /// Returns a boolean indicating whether two symbol contexts correspond to
+ /// the same function. If the plugin has no opinion, it should return
nullopt.
+ virtual std::optional
+ Are
https://github.com/felipepiovezan updated
https://github.com/llvm/llvm-project/pull/112720
>From 231afe21bc48b3530dc11bc50a24085043807917 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan
Date: Thu, 17 Oct 2024 06:00:31 -0700
Subject: [PATCH] [lldb] Introduce Language::AreEqualForFrameC
jimingham wrote:
> > > > do we have in mind any other languages that will implement this?
> > >
> > >
> > > I suspect any language wanting to implement this notion of function
> > > splitting (e.g. all the users of corosplitter) and virtual frames could
> > > have a use for this
> >
> >
> >
@@ -13,6 +13,13 @@
# the building of the a.out executable program. For example,
# DYLIB_ONLY := YES
#
+# When specifying one of the DYLIB_*_SOURCES variables, DYLIB_NAME
+# controls the name of the produced dylib. E.g., if set to "foo",
+# the generated dylib will be called "f
@@ -363,6 +363,14 @@ class Language : public PluginInterface {
return false;
}
+ /// Returns a boolean indicating whether two symbol contexts correspond to
+ /// the same function. If the plugin has no opinion, it should return
nullopt.
+ virtual std::optional
+ Are
https://github.com/kusmour updated
https://github.com/llvm/llvm-project/pull/112657
>From 48831c67f07e1199145dbb5538c02f502d3f02bf Mon Sep 17 00:00:00 2001
From: Wanyi Ye
Date: Mon, 14 Oct 2024 22:37:50 -0700
Subject: [PATCH] [lldb] Fix write only file action to truncate the file
---
lldb/sou
https://github.com/kusmour edited
https://github.com/llvm/llvm-project/pull/112657
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
kusmour wrote:
@DavidSpickett If you don't mind me asking, how do we add to release note?
Thanks in advance!
https://github.com/llvm/llvm-project/pull/112657
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Adrian Prantl (adrian-prantl)
Changes
I've been getting complaints from users being spammed by -gmodules missing file
warnings going out of control because each object file depends on an entire DAG
of PCM files that usually are all missing
https://github.com/adrian-prantl created
https://github.com/llvm/llvm-project/pull/112801
I've been getting complaints from users being spammed by -gmodules missing file
warnings going out of control because each object file depends on an entire DAG
of PCM files that usually are all missing at
felipepiovezan wrote:
> > > do we have in mind any other languages that will implement this?
> >
> >
> > I suspect any language wanting to implement this notion of function
> > splitting (e.g. all the users of corosplitter) and virtual frames could
> > have a use for this
>
> We already have
https://github.com/JDevlieghere approved this pull request.
LGTM, thanks for fixing this!
https://github.com/llvm/llvm-project/pull/112801
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-c
@@ -13,6 +13,13 @@
# the building of the a.out executable program. For example,
# DYLIB_ONLY := YES
#
+# When specifying one of the DYLIB_*_SOURCES variables, DYLIB_NAME
+# controls the name of the produced dylib. E.g., if set to "foo",
+# the generated dylib will be called "f
@@ -0,0 +1,631 @@
+## This test verifies that loading an ELF file that has no section headers can
+## load the dynamic symbol table using the DT_SYMTAB, DT_SYMENT, DT_HASH or
+## the DT_GNU_HASH .dynamic key/value pairs that are loaded via the PT_DYNAMIC
+## segment.
+##
+## This
https://github.com/clayborg updated
https://github.com/llvm/llvm-project/pull/112596
>From 890d2bcf655a2e1e58b025cc0df7b4e42956e4c6 Mon Sep 17 00:00:00 2001
From: Greg Clayton
Date: Sat, 28 Sep 2024 15:05:37 -0700
Subject: [PATCH 1/2] Add support for reading the dynamic symbol table from
progr
https://github.com/clayborg approved this pull request.
https://github.com/llvm/llvm-project/pull/108448
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Jacob Lalonde
Date: 2024-10-17T15:26:05-07:00
New Revision: 5033ea73bb01061feb09b3216c74619e1fbefdeb
URL:
https://github.com/llvm/llvm-project/commit/5033ea73bb01061feb09b3216c74619e1fbefdeb
DIFF:
https://github.com/llvm/llvm-project/commit/5033ea73bb01061feb09b3216c74619e1fbefdeb.diff
https://github.com/Jlalond closed
https://github.com/llvm/llvm-project/pull/108448
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jasonmolenda wrote:
FTR I have an intel mac running the same OS as the CI bots (`LLVM host triple:
x86_64-apple-darwin22.6.0` it's macOS 13.5 aka macOS Ventura from 2022), and am
building github main so I can try to repo this failure and Alex's on this shell
test. I don't really think I'm goi
@@ -1158,11 +1175,7 @@ void
ClangASTImporter::ASTImporterDelegate::ImportDefinitionTo(
to_tag->setCompleteDefinition(from_tag->isCompleteDefinition());
if (Log *log_ast = GetLog(LLDBLog::AST)) {
-std::string name_string;
-if (NamedDecl *from_named_
@@ -1136,6 +1136,25 @@ ClangASTImporter::ASTImporterDelegate::ImportImpl(Decl
*From) {
void ClangASTImporter::ASTImporterDelegate::ImportDefinitionTo(
clang::Decl *to, clang::Decl *from) {
+ Log *log = GetLog(LLDBLog::Expressions);
+
+ auto getDeclName = [](Decl const *
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/112748
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -102,11 +102,9 @@ llvm::Error CommandObjectMultiword::LoadUserSubcommand(
std::string str_name(name);
- auto pos = m_subcommand_dict.find(str_name);
- if (pos == m_subcommand_dict.end()) {
-m_subcommand_dict[str_name] = cmd_obj_sp;
+ auto [pos, inserted] = m_subco
https://github.com/labath approved this pull request.
https://github.com/llvm/llvm-project/pull/112823
___
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/112811
This is the second half of https://github.com/llvm/llvm-project/pull/90008.
Essentially, it replace the work of resolving template types when we just need
the qualified names with walking the DIE tree in `DWAR
Author: Jason Molenda
Date: 2024-10-17T19:46:08-07:00
New Revision: 9c6f85f57a74278e4833f3da2606d80e7577d6d5
URL:
https://github.com/llvm/llvm-project/commit/9c6f85f57a74278e4833f3da2606d80e7577d6d5
DIFF:
https://github.com/llvm/llvm-project/commit/9c6f85f57a74278e4833f3da2606d80e7577d6d5.diff
@@ -0,0 +1,243 @@
+//===-- ObjectFileXCOFF.cpp
+//-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff e9eec14bb3566f6578950797559de98678f16985
e996ae0076881bc9f660f75baeb9522ff7af49e4 --e
https://github.com/kazutakahirata created
https://github.com/llvm/llvm-project/pull/112823
None
>From 621d5b5a767daa4046dffec522c39e4bc652ac1b Mon Sep 17 00:00:00 2001
From: Kazu Hirata
Date: Thu, 17 Oct 2024 07:52:35 -0700
Subject: [PATCH] [lldb] Avoid repeated map lookups (NFC)
---
lldb/so
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Kazu Hirata (kazutakahirata)
Changes
---
Full diff: https://github.com/llvm/llvm-project/pull/112823.diff
1 Files Affected:
- (modified) lldb/source/Commands/CommandObjectMultiword.cpp (+2-4)
``diff
diff --git a/lldb/source/C
https://github.com/DhruvSrivastavaX edited
https://github.com/llvm/llvm-project/pull/111814
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,243 @@
+//===-- ObjectFileXCOFF.cpp
+//-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier
@@ -0,0 +1,243 @@
+//===-- ObjectFileXCOFF.cpp
+//-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier
https://github.com/labath commented:
This is exactly what I had in mind -- thank you.
The patch looks mostly good, apart from the inline comments. My main question
is about the "dependant modules" parsing code. AFAICT, its not actually
functional (and not tested). Is yaml2objs xcoff backend su
https://github.com/labath edited
https://github.com/llvm/llvm-project/pull/111814
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,243 @@
+//===-- ObjectFileXCOFF.cpp
+//-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier
@@ -0,0 +1,243 @@
+//===-- ObjectFileXCOFF.cpp
+//-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier
@@ -0,0 +1,243 @@
+//===-- ObjectFileXCOFF.cpp
+//-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier
@@ -0,0 +1,116 @@
+//===-- ObjectFileXCOFF.h --- -*- C++
+//-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier
felipepiovezan wrote:
Thanks for finding those, there are many places in LLDB doing repeated work
like this!
https://github.com/llvm/llvm-project/pull/112655
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
felipepiovezan wrote:
An example usage can be found here:
https://github.com/swiftlang/llvm-project/pull/9441
https://github.com/llvm/llvm-project/pull/112720
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mai
1 - 100 of 137 matches
Mail list logo
