dsanders added a comment.
> The route cause of your problem is that ReadRegisterUnsigned returns a value
> where the 32 MSB is garbage while the
> expected behavior is to zero out those bits (it works on i386 and arm
> AFAIK). You should find out why that is happening
> and fix the root caus
Author: dsanders
Date: Tue Sep 15 11:33:17 2015
New Revision: 247703
URL: http://llvm.org/viewvc/llvm-project?rev=247703&view=rev
Log:
Fix build after llvm r247683 was reverted.
Modified:
lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp
Modified: lldb/trunk/source/Plugins/D
dsanders created this revision.
dsanders added a subscriber: lldb-commits.
http://reviews.llvm.org/D12900
Files:
tools/lldb-server/CMakeLists.txt
Index: tools/lldb-server/CMakeLists.txt
===
--- tools/lldb-server/CMakeLists.txt
+++
dsanders added a comment.
This patch does the trick for me but I'm not certain it's the right fix
overall. Could someone take a look?
http://reviews.llvm.org/D12900
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi
dsanders updated this revision to Diff 35075.
dsanders added a comment.
Pavel's suggestion to use LLDB_SYSTEM_LIBS works for me. Updated the patch.
http://reviews.llvm.org/D12900
Files:
tools/lldb-server/CMakeLists.txt
Index: tools/lldb-server/CMakeLists.txt
=
dsanders created this revision.
dsanders added subscribers: krytarowski, labath, lldb-commits.
Following on from r247991:
pthread is in LLDB_SYSTEM_LIBS so there's no need to explicitly add it to the
link.
http://reviews.llvm.org/D12964
Files:
tools/lldb-server/CMakeLists.txt
Index: tools/ll
dsanders updated this revision to Diff 35086.
dsanders added a comment.
Correct the patch. Arcanist created the diff based on a revision prior to
r247991 for some reason.
http://reviews.llvm.org/D12964
Files:
tools/lldb-server/CMakeLists.txt
Index: tools/lldb-server/CMakeLists.txt
=
dsanders added a comment.
Thanks. I've acquired a new link failure (this time on lldb-mi) since my last
build so I'll commit this once I have a temporary fix in place for that and can
run the tests again.
http://reviews.llvm.org/D12964
___
lldb-co
dsanders added a comment.
'ninja clean' seems to have made the lldb-mi link failure go away. Presumably
something didn't rebuild when the references to llvm_regcomp and llvm_regfree
were added.
I'll run the lldb tests and then commit this.
http://reviews.llvm.org/D12964
___
Author: dsanders
Date: Mon Sep 21 12:23:22 2015
New Revision: 248177
URL: http://llvm.org/viewvc/llvm-project?rev=248177&view=rev
Log:
[lldb-server] No need to add pthread twice.
Summary:
Following on from r247991:
pthread is in LLDB_SYSTEM_LIBS so there's no need to explicitly add it to the
lin
This revision was automatically updated to reflect the committed changes.
Closed by commit rL248177: [lldb-server] No need to add pthread twice.
(authored by dsanders).
Changed prior to commit:
http://reviews.llvm.org/D12964?vs=35086&id=35277#toc
Repository:
rL LLVM
http://reviews.llvm.org/
dsanders created this revision.
dsanders added subscribers: lldb-commits, labath, krytarowski.
http://reviews.llvm.org/D13027
Files:
tools/lldb-mi/CMakeLists.txt
Index: tools/lldb-mi/CMakeLists.txt
===
--- tools/lldb-mi/CMakeLists
dsanders added a comment.
It seems I spoke too soon when I said the link error went away after a clean
build. This patch fixes it.
http://reviews.llvm.org/D13027
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bi
Author: dsanders
Date: Tue Sep 22 04:08:44 2015
New Revision: 248251
URL: http://llvm.org/viewvc/llvm-project?rev=248251&view=rev
Log:
[lldb-mi] Fix unresolved reference to llvm_regcomp and llvm_regfree.
Subscribers: krytarowski, labath, lldb-commits
Differential Revision: http://reviews.llvm.or
This revision was automatically updated to reflect the committed changes.
Closed by commit rL248251: [lldb-mi] Fix unresolved reference to llvm_regcomp
and llvm_regfree. (authored by dsanders).
Changed prior to commit:
http://reviews.llvm.org/D13027?vs=35278&id=35351#toc
Repository:
rL LLVM
https://github.com/dsandersllvm updated
https://github.com/llvm/llvm-project/pull/150732
>From bd27929645928939f319dc915da1a4636e4d317d Mon Sep 17 00:00:00 2001
From: Daniel Sanders
Date: Wed, 28 Aug 2024 19:02:21 -0700
Subject: [PATCH 1/4] [lldb] Implement DW_CFA_val_offset and
DW_CFA_val_off
https://github.com/dsandersllvm updated
https://github.com/llvm/llvm-project/pull/150732
>From bd27929645928939f319dc915da1a4636e4d317d Mon Sep 17 00:00:00 2001
From: Daniel Sanders
Date: Wed, 28 Aug 2024 19:02:21 -0700
Subject: [PATCH 1/3] [lldb] Implement DW_CFA_val_offset and
DW_CFA_val_off
dsandersllvm wrote:
While looking into that, I found a couple mistakes that made me question how it
managed to work and I found that that bit is not actually used.
ConcreteRegisterLocation uses eRegisterIsRegisterPlusOffset for all
reg+offset's including reg=CFA, but AbstractRegisterLocation h
https://github.com/dsandersllvm created
https://github.com/llvm/llvm-project/pull/150732
The test for this is artificial as I'm not aware of any upstream targets that
use DW_CFA_val_offset
RegisterContextUnwind::ReadFrameAddress now reports how it's attempting to
obtain the CFA unless all suc
https://github.com/dsandersllvm updated
https://github.com/llvm/llvm-project/pull/150732
>From bd27929645928939f319dc915da1a4636e4d317d Mon Sep 17 00:00:00 2001
From: Daniel Sanders
Date: Wed, 28 Aug 2024 19:02:21 -0700
Subject: [PATCH 1/7] [lldb] Implement DW_CFA_val_offset and
DW_CFA_val_off
dsandersllvm wrote:
That makes sense, I've added the command and switched to register read to avoid
the expression evaluator
https://github.com/llvm/llvm-project/pull/150732
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.
https://github.com/dsandersllvm closed
https://github.com/llvm/llvm-project/pull/150732
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/dsandersllvm updated
https://github.com/llvm/llvm-project/pull/150732
>From bd27929645928939f319dc915da1a4636e4d317d Mon Sep 17 00:00:00 2001
From: Daniel Sanders
Date: Wed, 28 Aug 2024 19:02:21 -0700
Subject: [PATCH 1/6] [lldb] Implement DW_CFA_val_offset and
DW_CFA_val_off
https://github.com/dsandersllvm updated
https://github.com/llvm/llvm-project/pull/150732
>From bd27929645928939f319dc915da1a4636e4d317d Mon Sep 17 00:00:00 2001
From: Daniel Sanders
Date: Wed, 28 Aug 2024 19:02:21 -0700
Subject: [PATCH 1/5] [lldb] Implement DW_CFA_val_offset and
DW_CFA_val_off
dsandersllvm wrote:
I've added a test case to confirm it is read correctly computing the value. As
I pushed it, it occurred to me that I should make the offset non-zero so I'll
fix that quick.
I don't think the non-standard return pointer bit from
eh-frame-dwarf-unwind.test should be necessar
dsandersllvm wrote:
I don't think combining them in ConcreteRegisterLocation completely makes sense
like it did for AbstractRegisterLocation because there's a difference in
semantics. eRegisterInRegister refers to a storage location whereas
eRegisterIsRegisterPlusOffset is a computed value wit
https://github.com/dsandersllvm created
https://github.com/llvm/llvm-project/pull/155000
This allows the debugger to evaluate expressions without requiring the
expression to be CodeGen'd and executed on the target. This should be more
efficient for many existing targets but is necessary for targ
https://github.com/dsandersllvm updated
https://github.com/llvm/llvm-project/pull/155000
>From 3ac398b2fad8d30a23d196c15a9cb9f1bd43fdcb Mon Sep 17 00:00:00 2001
From: Daniel Sanders
Date: Fri, 22 Aug 2025 10:54:52 -0700
Subject: [PATCH 1/4] [lldb] Add some vector operations to the IRInterpreter
https://github.com/dsandersllvm updated
https://github.com/llvm/llvm-project/pull/155000
>From 3ac398b2fad8d30a23d196c15a9cb9f1bd43fdcb Mon Sep 17 00:00:00 2001
From: Daniel Sanders
Date: Fri, 22 Aug 2025 10:54:52 -0700
Subject: [PATCH 1/3] [lldb] Add some vector operations to the IRInterpreter
https://github.com/dsandersllvm updated
https://github.com/llvm/llvm-project/pull/155000
>From be4ddf49a230b32699df153ecc3b2b3ee62c1c22 Mon Sep 17 00:00:00 2001
From: Daniel Sanders
Date: Fri, 22 Aug 2025 10:54:52 -0700
Subject: [PATCH 1/7] [lldb] Add some vector operations to the IRInterpreter
@@ -644,7 +723,25 @@ bool IRInterpreter::CanInterpret(llvm::Module &module,
llvm::Function &function,
switch (operand_type->getTypeID()) {
default:
break;
-case Type::FixedVectorTyID:
+case Type::FixedVectorTyID: {
dsa
dsandersllvm wrote:
> For testing the endianess, I'm not sure we have PPC LLDB buildbots that would
> test this (@DavidSpickett or @JDevlieghere might know). Any chance this can
> be tested with unit-tests somehow? Maybe we can just pass an LLVM IR module
> into the IRInterpreter? We could pot
@@ -30,9 +30,14 @@ class ArchitecturePPC64 : public Architecture {
void AdjustBreakpointAddress(const Symbol &func,
Address &addr) const override;
+ lldb::ByteOrder GetVectorElementOrder() const override;
+
private:
static std::unique_ptr
https://github.com/dsandersllvm closed
https://github.com/llvm/llvm-project/pull/157196
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/dsandersllvm edited
https://github.com/llvm/llvm-project/pull/157198
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
dsandersllvm wrote:
> > Some targets like PowerPC store their
>
> Is there some text missing here?
Oops, fixed it.
> Do we know what vector extension s390x/SystemZ has and what order it uses?
I don't know but I've found
https://github.com/bytecodealliance/wasmtime/issues/4566 so @uweigand mi
36 matches
Mail list logo
