Author: Jason Molenda
Date: 2025-09-08T10:37:16-07:00
New Revision: 693146dcc0a1d653827cc88993acf52428af1a94
URL:
https://github.com/llvm/llvm-project/commit/693146dcc0a1d653827cc88993acf52428af1a94
DIFF:
https://github.com/llvm/llvm-project/commit/693146dcc0a1d653827cc88993acf52428af1a94.diff
https://github.com/jasonmolenda closed
https://github.com/llvm/llvm-project/pull/159849
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jasonmolenda created
https://github.com/llvm/llvm-project/pull/159849
The Mach-O file format has several load commands which specify the location of
data in the file in UInt32 offsets. lldb uses these same structures to track
the offsets of the binary in virtual address spa
@@ -293,6 +293,9 @@ void RegisterContextUnwind::InitializeZerothFrame() {
return;
}
+ // Give the Architecture a chance to replace the UnwindPlan.
+ AdoptArchitectureUnwindPlan();
jasonmolenda wrote:
When we create a new stack frame (starting with the
https://github.com/jasonmolenda approved this pull request.
This looks fine, although we're not using `tbi_mask` anywhere now? We should
probably remove it if it's not being used.
https://github.com/llvm/llvm-project/pull/159612
___
lldb-commits mail
https://github.com/jasonmolenda approved this pull request.
LGTM. The early Fixing of the register value before doing a memory read is
from early in our adoption of AArch64 PAC where the bits would not be cleared
at use-time when we read/write memory.
https://github.com/llvm/llvm-project/pull
Author: Jason Molenda
Date: 2025-09-10T22:58:30-07:00
New Revision: 6a719387704c8c01b29bdb418a4d8a3b5df6b090
URL:
https://github.com/llvm/llvm-project/commit/6a719387704c8c01b29bdb418a4d8a3b5df6b090
DIFF:
https://github.com/llvm/llvm-project/commit/6a719387704c8c01b29bdb418a4d8a3b5df6b090.diff
https://github.com/jasonmolenda approved this pull request.
Nice fix, good job on coming up with a test for it too, that's a lot of setup
for this.
https://github.com/llvm/llvm-project/pull/159460
___
lldb-commits mailing list
lldb-commits@lists.llvm.
Author: Jason Molenda
Date: 2025-09-11T14:19:44-07:00
New Revision: 20e55f359dc424fa23392ad7ecd766294b60accc
URL:
https://github.com/llvm/llvm-project/commit/20e55f359dc424fa23392ad7ecd766294b60accc
DIFF:
https://github.com/llvm/llvm-project/commit/20e55f359dc424fa23392ad7ecd766294b60accc.diff
https://github.com/jasonmolenda approved this pull request.
Tried a few different inputs and the old & new versions are producing the same
results.
https://github.com/llvm/llvm-project/pull/158119
___
lldb-commits mailing list
lldb-commits@lists.llvm.
@@ -799,6 +799,23 @@ Status ProcessMachCore::DoGetMemoryRegionInfo(addr_t
load_addr,
region_info.SetMapped(MemoryRegionInfo::eNo);
}
return Status();
+ } else {
+// The corefile has no LC_SEGMENT at this virtual address,
+// but see if there is a binary
https://github.com/jasonmolenda approved this pull request.
https://github.com/llvm/llvm-project/pull/157498
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Jason Molenda
Date: 2025-09-09T16:47:26-07:00
New Revision: f3b7ad4859037254afc0ee6d938018376c7c03d3
URL:
https://github.com/llvm/llvm-project/commit/f3b7ad4859037254afc0ee6d938018376c7c03d3
DIFF:
https://github.com/llvm/llvm-project/commit/f3b7ad4859037254afc0ee6d938018376c7c03d3.diff
jasonmolenda wrote:
> [lldb-remote-linux-win](https://lab.llvm.org/buildbot/#/builders/197/builds/8706)
> and
> [lldb-x86_64-win](https://lab.llvm.org/buildbot/#/builders/211/builds/1871)
> are still broken.
@slydiman @skipIfWindows fixed the lldb-x86_64-win bot, but
lldb-remote-linux-win is
@@ -0,0 +1,51 @@
+"""
+Test that we can backtrace up an ARM Cortex-M Exception return stack
+"""
+
+import lldb
+import json
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TestCortexMExceptionUnwind(T
jasonmolenda wrote:
Thanks. I've asked someone with access to a Windows system to help me
understand if this is an issue with my new yaml2macho-core utility (producing
incorrect corefiles) or a problem with lldb on Windows reading (32-bit?) mach-o
corefiles, I'll hold off on tweaking this any
Author: Jason Molenda
Date: 2025-09-04T19:57:05-07:00
New Revision: e7572d73b5fabe69844c943b776495121774
URL:
https://github.com/llvm/llvm-project/commit/e7572d73b5fabe69844c943b776495121774
DIFF:
https://github.com/llvm/llvm-project/commit/e7572d73b5fabe69844c943b776495121774.diff
Author: Jason Molenda
Date: 2025-09-04T19:53:16-07:00
New Revision: 4c17749b6d26093f33efd13f798d47b893252b15
URL:
https://github.com/llvm/llvm-project/commit/4c17749b6d26093f33efd13f798d47b893252b15
DIFF:
https://github.com/llvm/llvm-project/commit/4c17749b6d26093f33efd13f798d47b893252b15.diff
jasonmolenda wrote:
> > You could imagine someone making an ELF corefile output capability, for
> > instance.
>
> Yes I'd love to be generating the core files eventually. Maybe we can with
> yaml2obj but I never seriously looked into it. As right now, patching in
> notes by hand makes for sma
jasonmolenda wrote:
This change looks good to me. I might not have read it sufficiently closely,
but the duplicate symbols we're looking at here are only when there are debug
map entries for .o file debugging, maybe?
Could you please update the code that's duplicate circa line 2800 too.
O
https://github.com/jasonmolenda created
https://github.com/llvm/llvm-project/pull/156099
The qSpeedTest packet is used for experiments to determine the optimal packet
size for a given communication medium, e.g. to transfer 10MB of memory, is it
faster to send a hundred 100KB packets or ten 1MB
@@ -150,3 +158,161 @@ addr_t ArchitectureArm::GetOpcodeLoadAddress(addr_t
opcode_addr,
}
return opcode_addr & ~(1ull);
}
+
+// The ARM M-Profile Armv7-M Architecture Reference Manual
+// "Exception return behavior" describes how the processor
+// saves registers to the sta
https://github.com/jasonmolenda edited
https://github.com/llvm/llvm-project/pull/153922
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -150,3 +158,161 @@ addr_t ArchitectureArm::GetOpcodeLoadAddress(addr_t
opcode_addr,
}
return opcode_addr & ~(1ull);
}
+
+// The ARM M-Profile Armv7-M Architecture Reference Manual
+// "Exception return behavior" describes how the processor
+// saves registers to the sta
@@ -129,6 +130,14 @@ class Architecture : public PluginInterface {
RegisterContext ®_context) const {
return false;
}
+
+ /// Return an UnwindPlan that allows architecture-defined rules for finding
+ /// saved registers, given a pa
https://github.com/jasonmolenda closed
https://github.com/llvm/llvm-project/pull/155733
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/155733
>From 9f6f67403bac881ace1f79327f6cdb612765e478 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Wed, 27 Aug 2025 17:54:34 -0700
Subject: [PATCH] [lldb][debugserver] Upstream to debugserver changes
Review
jasonmolenda wrote:
> did not mean to click the update button, sorry!
>
> I will try the JSON symbol file route. I think we can make a new tagged
> address symbol overlapping an existing one.
I'm sure you remember seeing it, but I created one of these for a test case in
https://github.com
@@ -244,6 +266,7 @@ kern_return_t DNBArchMachARM64::GetGPRState(bool force) {
uint64_t log_sp = m_state.context.gpr.__sp;
uint64_t log_pc = m_state.context.gpr.__pc;
#endif
+uint64_t *x = &m_state.context.gpr.__x[0];
jasonmolenda wrote:
Yeah, in th
https://github.com/jasonmolenda created
https://github.com/llvm/llvm-project/pull/155733
Review of diffs from lldb's internal debugserver and llvm.org main found two
orphaned changes that should be upstreamed.
First is in MachTask::ExceptionThread where we want to confirm that a mach
exceptio
@@ -0,0 +1,223 @@
+//===-- main.cppp
-===//
+//
+// 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: Ap
@@ -0,0 +1,55 @@
+//===-- LCNoteWriter.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: Apa
@@ -0,0 +1,22 @@
+//===-- Utility.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: Apa
jasonmolenda wrote:
> I know this is a simple tool, but it seems like adding a bit of organization
> could go a long way. Essentially, the tool consists of 3 parts:
>
> 1. A reader that takes YAML and creates an in-memory/intermediate
> representation (CoreSpec).
> 2. A writer that takes a Cor
https://github.com/jasonmolenda closed
https://github.com/llvm/llvm-project/pull/154853
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jasonmolenda edited
https://github.com/llvm/llvm-project/pull/147990
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jasonmolenda edited
https://github.com/llvm/llvm-project/pull/147990
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jasonmolenda edited
https://github.com/llvm/llvm-project/pull/153911
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/153911
>From 69ed12fb21bbdde89bf43b1356c5542912655318 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Fri, 15 Aug 2025 18:23:10 -0700
Subject: [PATCH 1/8] [lldb] Add utility to create Mach-O corefile from YAML
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/153911
>From 69ed12fb21bbdde89bf43b1356c5542912655318 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Fri, 15 Aug 2025 18:23:10 -0700
Subject: [PATCH 1/6] [lldb] Add utility to create Mach-O corefile from YAML
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/153911
>From 69ed12fb21bbdde89bf43b1356c5542912655318 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Fri, 15 Aug 2025 18:23:10 -0700
Subject: [PATCH 1/5] [lldb] Add utility to create Mach-O corefile from YAML
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/153922
>From eac74f99eab04524756ed6220b10fea9c991ba09 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Fri, 15 Aug 2025 20:58:22 -0700
Subject: [PATCH 1/5] [lldb] Unwind through ARM Cortex-M exceptions
automati
https://github.com/jasonmolenda edited
https://github.com/llvm/llvm-project/pull/153922
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/153922
>From eac74f99eab04524756ed6220b10fea9c991ba09 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Fri, 15 Aug 2025 20:58:22 -0700
Subject: [PATCH 1/4] [lldb] Unwind through ARM Cortex-M exceptions
automati
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/153922
>From eac74f99eab04524756ed6220b10fea9c991ba09 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Fri, 15 Aug 2025 20:58:22 -0700
Subject: [PATCH 1/3] [lldb] Unwind through ARM Cortex-M exceptions
automati
https://github.com/jasonmolenda edited
https://github.com/llvm/llvm-project/pull/153922
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/153922
>From eac74f99eab04524756ed6220b10fea9c991ba09 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Fri, 15 Aug 2025 20:58:22 -0700
Subject: [PATCH 1/2] [lldb] Unwind through ARM Cortex-M exceptions
automati
https://github.com/jasonmolenda edited
https://github.com/llvm/llvm-project/pull/153911
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jasonmolenda wrote:
I think @labath would point out that I'm doing an end-run around making a
sufficient Mock Process capability, with memory and threads and symbols, to
write unit tests. @medismailben would point out that we could write a Scripted
Process python script that would ingest this
https://github.com/jasonmolenda created
https://github.com/llvm/llvm-project/pull/153922
When a processor faults/is interrupted/gets an exception, it will stop running
code and jump to an exception catcher routine. Most processors will store the
pc that was executing in a system register, and
jasonmolenda wrote:
The Linux PR pre-merge testing is failing because lldb/tool/yaml2macho-core is
not being built. I think I need to add a dependency maybe in
test/CMakeLists.txt? I was doing all of my development with simply `ninja` to
build everything, but I prob need to have this added t
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/153911
>From 69ed12fb21bbdde89bf43b1356c5542912655318 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Fri, 15 Aug 2025 18:23:10 -0700
Subject: [PATCH 1/4] [lldb] Add utility to create Mach-O corefile from YAML
jasonmolenda wrote:
Ah, I included an implementation to ObjectFileJSON::SetLoadAddress in this PR,
which isn't actually relevant to the new tool or use of it. It's for the
testcase I am writing for the Cortex-M backtrace, where I will have an
ObjectFileJSON binary specification and I needed t
jasonmolenda wrote:
One thing I wasn't thrilled about with llvm's yaml MappingTraits parser was
that I need to define register values like
```
registers: [
{name: x0, value: 0x0001}, {name: x1, value:
0x00016fdff3c0},
{name: x2, value: 0x00016fd
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/153911
>From 69ed12fb21bbdde89bf43b1356c5542912655318 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Fri, 15 Aug 2025 18:23:10 -0700
Subject: [PATCH 1/3] [lldb] Add utility to create Mach-O corefile from YAML
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/153911
>From 69ed12fb21bbdde89bf43b1356c5542912655318 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Fri, 15 Aug 2025 18:23:10 -0700
Subject: [PATCH 1/2] [lldb] Add utility to create Mach-O corefile from YAML
https://github.com/jasonmolenda edited
https://github.com/llvm/llvm-project/pull/153911
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jasonmolenda edited
https://github.com/llvm/llvm-project/pull/153911
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jasonmolenda edited
https://github.com/llvm/llvm-project/pull/153911
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jasonmolenda created
https://github.com/llvm/llvm-project/pull/153911
I've wanted a utility to create a corefile for test purposes given a bit of
memory and regsters, for a while. I've written a few API tests over the years
that needed exactly this capability -- we have sev
https://github.com/jasonmolenda approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/152798
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jasonmolenda approved this pull request.
This LGTM. Yes, I think lldb currently has a mix of "clean metadata bits when
we first see an address" and "clean metadata bits before using" (e.g.
Process::ReadMemory), and we should have a discussion about whether we should
keep a
@@ -148,6 +148,16 @@ else
endif
endif
+#--
+# Use LLD when cross compiling on Darwin.
+#--
+ifeq "$(HOST_OS)" "Darwin"
+ ifneq (,$(
@@ -355,6 +355,16 @@ ifeq "$(OS)" "Windows_NT"
endif
endif
+#--
+# Darwin cross compilation
+#--
+ifeq "$(HOST_OS)" "Darwin"
+
https://github.com/jasonmolenda approved this pull request.
lgtm.
https://github.com/llvm/llvm-project/pull/151403
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jasonmolenda edited
https://github.com/llvm/llvm-project/pull/151403
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jasonmolenda wrote:
> GDB code breaks actually can have a condition list that's evaluated on the
> target side:
>
> ```
> cond_list is an optional list of conditional expressions in bytecode form
> that should be evaluated on the target’s side. These are the conditions that
> should be taken
https://github.com/jasonmolenda edited
https://github.com/llvm/llvm-project/pull/151056
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jasonmolenda wrote:
I believe this change is safe and correct, but I think Felipe is going to kick
off a testsuite run with arch arm64e (where pointer authentication is enabled
on Darwin) to try to stress these codepaths and confirm that our understanding
is correct.
https://github.com/llvm/l
jasonmolenda wrote:
Felipe and I were discussing this earlier. We started (I started) with the
model of removing metadata bits -- e.g. Pointer Authentication, or Top Byte
Ignore -- from addresses as early as possible in the lldb codebase. We would
pass around "Fixed" or sanitized or stripped
@@ -1998,6 +1998,18 @@ threads (live system debug) / cores (JTAG) in your
program have
stopped and allows LLDB to display and control your program
correctly.
+## qWasmCallStack
+
+Get the Wasm callback for the given thread id. This returns a hex-encoding list
+of 64-bit addre
@@ -1998,6 +1998,18 @@ threads (live system debug) / cores (JTAG) in your
program have
stopped and allows LLDB to display and control your program
correctly.
+## qWasmCallStack
+
+Get the Wasm callback for the given thread id. This returns a hex-encoding list
+of 64-bit addre
https://github.com/jasonmolenda approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/149620
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jasonmolenda wrote:
Incidentally, this is always something get a little confused by when reading
assembly, we see it with backtraces. A CALL instruction executes and the
return address is the next instruction. That confuses people looking at the
assembly language -- the "pc" pointer is point
jasonmolenda wrote:
Interesting PR, thanks for looking at adding these annotations. I think
exposing these dwarf location expressions in a more user-visible way is going
to put a lot of pressure on making them more meaningful to users, as opposed to
debugging prints for debugger/compiler deve
@@ -2015,8 +2015,6 @@ llvm::Expected DWARFExpression::Evaluate(
if (stack.size() < 1) {
UpdateValueTypeFromLocationDescription(log, dwarf_cu,
LocationDescriptionKind::Empty);
-// Reset for the next piece.
-
@@ -2015,8 +2015,6 @@ llvm::Expected DWARFExpression::Evaluate(
if (stack.size() < 1) {
UpdateValueTypeFromLocationDescription(log, dwarf_cu,
LocationDescriptionKind::Empty);
-// Reset for the next piece.
-
jasonmolenda wrote:
The general discussion of how to test this class of change is interesting, but
I don't want to lose sight of the fact that this PR will not work. It does
nothing but break existing functionality for RISC-V users (disabling
instruction emulation used to do instruction stepp
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/148105
>From 74995e8f1a982a82bafaa150fb407187fa4b95e4 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Thu, 10 Jul 2025 22:31:54 -0700
Subject: [PATCH 1/6] [lldb][WIP] dump riscv opcode bytes as blocks of 2/4
b
jasonmolenda wrote:
I didn't little-endian swap the bytes for the 48-bit and 64-bit instructions
properly in my unit test, which is why those two were failing. Fixed now.
https://github.com/llvm/llvm-project/pull/148105
___
lldb-commits mailing list
jasonmolenda wrote:
nb: I didn't little-endian swap the bytes for the 48-bit and 64-bit
instructions properly in my unit test in
https://github.com/llvm/llvm-project/pull/148105 , which is why those tests
were failing. Fixed.
https://github.com/llvm/llvm-project/pull/145793
_
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/148105
>From 74995e8f1a982a82bafaa150fb407187fa4b95e4 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Thu, 10 Jul 2025 22:31:54 -0700
Subject: [PATCH 1/5] [lldb][WIP] dump riscv opcode bytes as blocks of 2/4
b
jasonmolenda wrote:
I'm also getting back an instruction size of 2 for the 48-bit instruction, in
my unit test, it looks like.
https://github.com/llvm/llvm-project/pull/145793
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llv
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/148105
>From 74995e8f1a982a82bafaa150fb407187fa4b95e4 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Thu, 10 Jul 2025 22:31:54 -0700
Subject: [PATCH 1/4] [lldb][WIP] dump riscv opcode bytes as blocks of 2/4
b
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/148105
>From 74995e8f1a982a82bafaa150fb407187fa4b95e4 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Thu, 10 Jul 2025 22:31:54 -0700
Subject: [PATCH 1/3] [lldb][WIP] dump riscv opcode bytes as blocks of 2/4
b
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/148105
>From 74995e8f1a982a82bafaa150fb407187fa4b95e4 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Thu, 10 Jul 2025 22:31:54 -0700
Subject: [PATCH 1/2] [lldb][WIP] dump riscv opcode bytes as blocks of 2/4
b
jasonmolenda wrote:
I mentioned it last week but I know there was a lot of different comments on
this PR, so I wanted to be more clear about what I was talking about. The
Opcode class is given a Type argument which it uses to decide how to format the
bytes when it Dumps them. But this PR add
https://github.com/jasonmolenda created
https://github.com/llvm/llvm-project/pull/148105
Part of the changes by Ted Woodward et al in
https://github.com/llvm/llvm-project/pull/145793
to change the riscv disassemble --bytes mode output to match llvm-objdump
prints the instruction bytes as sequen
https://github.com/jasonmolenda edited
https://github.com/llvm/llvm-project/pull/147434
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jasonmolenda edited
https://github.com/llvm/llvm-project/pull/147434
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jasonmolenda wrote:
If you look at an existing EmulateInstruction target plugin that we live on
today, such as ARM64, it returns context types for
`UnwindAssemblyInstEmulation` like
```
eContextAdjustBaseRegister
eContextAdjustStackPointer
eContextAdvancePC
eContextImmediate
eContextPopRegist
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/147011
>From bf1838f4676bab0f7c998d3dbb03b6b593103335 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Fri, 4 Jul 2025 00:11:30 -0700
Subject: [PATCH 1/2] [lldb] Pass address expression command args through
Fix
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/147011
>From bf1838f4676bab0f7c998d3dbb03b6b593103335 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Fri, 4 Jul 2025 00:11:30 -0700
Subject: [PATCH 1/3] [lldb] Pass address expression command args through
Fix
jasonmolenda wrote:
FTR armv7 has one of the few FixCodeAddress methods that actually clears the
low bits, because the low bit is sometimes used to indicate arm/thumb processor
state of functions.
https://github.com/llvm/llvm-project/pull/147011
___
jasonmolenda wrote:
I didn't have a solid way to test this except rely on the arm-ubuntu bot, so I
enhanced a random armv7 mach-o corefile creator tool I wrote ages ago to add a
memory segment, and try to read from an odd address to confirm that it behaves
correctly, but this test will only ru
jasonmolenda wrote:
I can't imagine which 32-bit arm hater made this kind of change originally.
https://github.com/llvm/llvm-project/pull/147011
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/l
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/147011
>From bf1838f4676bab0f7c998d3dbb03b6b593103335 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Fri, 4 Jul 2025 00:11:30 -0700
Subject: [PATCH] [lldb] Pass address expression command args through
FixAnyA
https://github.com/jasonmolenda created
https://github.com/llvm/llvm-project/pull/147011
Commands that take an address expression/address through the
OptionArgParser::ToAddress method, which has filtered this user-specified
address through one of the Process Fix methods to clear non-addressabl
https://github.com/jasonmolenda approved this pull request.
Seems like a reasonable RP to me.
https://github.com/llvm/llvm-project/pull/146972
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lld
Author: Jason Molenda
Date: 2025-07-02T11:16:04-07:00
New Revision: 00e071d6906246192b344f3e28d9e15a0e0faf68
URL:
https://github.com/llvm/llvm-project/commit/00e071d6906246192b344f3e28d9e15a0e0faf68
DIFF:
https://github.com/llvm/llvm-project/commit/00e071d6906246192b344f3e28d9e15a0e0faf68.diff
1 - 100 of 1495 matches
Mail list logo
