https://github.com/jasonmolenda approved this pull request.
https://github.com/llvm/llvm-project/pull/112639
___
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
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
jasonmolenda wrote:
I built the swiftlang `rebranch` sources clean, with the parallel patch, with
the parallel plus preload patch. I ran them against the same Slack binary with
934 binary images, 10 of them outside the shared cache. I built them something
like
```
swift/utils/build-script --
jasonmolenda wrote:
This is interesting, sorry the uncached unwindplans made it harder to debug.
I've seen cold function outlining in our libraries but I've never looked at the
generated DWARF - does the function die have a location list with the main
function body and the .cold.1 function b
jasonmolenda wrote:
Let me just take a peek at some Darwin binaries with this codegen & their
debuginfo, and then i'll approve unless there's something I've misunderstood
about what we're looking at. It really makes me think that we are going to
need discontiguous ranges in the unwind plans t
https://github.com/jasonmolenda approved this pull request.
Looks good to me, thanks for putting this PR together. I can merge the PR for
you, if you don't have permissions to do that on llvm-project currently.
https://github.com/llvm/llvm-project/pull/111684
__
jasonmolenda wrote:
> > Was the setting intended for testing purposes only, or did you intend to
> > include that in a final PR?
>
> The latter. IMO the risks involved by parallelization are a bit too high to
> do it without a flag. I'm even thinking about having it opt-in rather than
> opt-o
jasonmolenda wrote:
For what it's worth, this thread pool for parallel processing has been used in
another part of lldb - it's used on ELF systems when processing DWARF, when we
need to scan the debug info in the individual .o files iirc. So we've had some
living-on time with the thread pool
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/110943
>From e1ea95287aeaa216e332aa221039247feaeb48e1 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Wed, 2 Oct 2024 17:45:36 -0700
Subject: [PATCH 1/2] [lldb][debugserver] Check if Rosetta debugserver exists
https://github.com/jasonmolenda closed
https://github.com/llvm/llvm-project/pull/110943
___
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.
Most of the review and discussion happened in the "non-preload" version of the
PR ( https://github.com/llvm/llvm-project/pull/110439 ), but I agree with
Dmitrii that this is the best approach to merge, this is approved. Very nice
job
jasonmolenda wrote:
Sounds good, I agree. I marked
https://github.com/llvm/llvm-project/pull/110646 as approved, please merge at
your convenience. Thanks again for spotting this opportunity for
multithreading and seeing it through!
https://github.com/llvm/llvm-project/pull/110439
__
https://github.com/jasonmolenda approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/113968
___
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.
LGTM.
https://github.com/llvm/llvm-project/pull/114507
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jasonmolenda wrote:
Looking at this again. The last issue that I needed to investigate was
Martin's mingw testsuite that had a regression when I landed it. The test
program was
https://github.com/mstorsjo/llvm-mingw/blob/master/test/hello-exception.cpp and
when run
```
bin/lldb -x -b -o 'b
https://github.com/jasonmolenda approved this pull request.
Quick review of the method being modified, this looks fine to me.
https://github.com/llvm/llvm-project/pull/115453
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.
jasonmolenda wrote:
Looks good to me, but Adrian might want a look.
https://github.com/llvm/llvm-project/pull/113508
___
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/115963
>From f8f1d70d1d9eac6d36c0fa84e2a94c032385da39 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Tue, 12 Nov 2024 15:55:15 -0800
Subject: [PATCH 1/2] [lldb] Handle an empty SBMemoryRegionInfo from scripted
@@ -288,8 +288,15 @@ Status ScriptedProcess::DoGetMemoryRegionInfo(lldb::addr_t
load_addr,
MemoryRegionInfo ®ion) {
Status error;
if (auto region_or_err =
- GetInterface().GetMemoryRegionContainingAddress(load_addr, er
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/115963
>From f8f1d70d1d9eac6d36c0fa84e2a94c032385da39 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Tue, 12 Nov 2024 15:55:15 -0800
Subject: [PATCH 1/3] [lldb] Handle an empty SBMemoryRegionInfo from scripted
https://github.com/jasonmolenda created
https://github.com/llvm/llvm-project/pull/115963
A scripted process implementation might return an SBMemoryRegionInfo object in
its implementation of `get_memory_region_containing_address` which will have an
address 0 and size 0, without realizing the pr
jasonmolenda wrote:
I am uncertain where I should detect an improperly formatted memory range. It
could be in `Process::GetMemoryRegionInfo`, which would catch a bad gdb remote
serial protocol response as well. Or it could be localized to
IRMemoryMap::FindSpace if we only wanted to avoid an
@@ -288,8 +288,15 @@ Status ScriptedProcess::DoGetMemoryRegionInfo(lldb::addr_t
load_addr,
MemoryRegionInfo ®ion) {
Status error;
if (auto region_or_err =
- GetInterface().GetMemoryRegionContainingAddress(load_addr, er
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/115963
>From f8f1d70d1d9eac6d36c0fa84e2a94c032385da39 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Tue, 12 Nov 2024 15:55:15 -0800
Subject: [PATCH 1/4] [lldb] Handle an empty SBMemoryRegionInfo from scripted
https://github.com/jasonmolenda approved this pull request.
LGTM, this is surely fallout from the 80 column reformat of '16, where these
tables used to have standard column positions (and very long lines).
https://github.com/llvm/llvm-project/pull/116089
___
@@ -157,6 +157,12 @@ let Definition = "target" in {
DefaultEnumValue<"eX86DisFlavorDefault">,
EnumValues<"OptionEnumValues(g_x86_dis_flavor_value_types)">,
Desc<"The default disassembly flavor to use for x86 or x86-64 targets.">;
+ def DisassemblyCPU: Property<"dis
@@ -1608,9 +1612,28 @@ void Target::SetExecutableModule(ModuleSP &executable_sp,
if (image_module_sp) {
added_modules.AppendIfNeeded(image_module_sp, false);
ObjectFile *objfile = image_module_sp->GetObjectFile();
- if (objfile)
+ i
https://github.com/jasonmolenda edited
https://github.com/llvm/llvm-project/pull/114507
___
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.
It took me a minute to understand how you were handling the locking of the
dependent file list while iterating across it, but now I see it. You grab the
lock at the beginning of the outer loop, then enqueue all of the
not-yet-process
jasonmolenda wrote:
Looks good to me, thanks for addressing this other bottleneck for launch
startup.
https://github.com/llvm/llvm-project/pull/114507
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/lis
@@ -3064,22 +3064,41 @@ static int gdb_errno_to_system(int err) {
static uint64_t ParseHostIOPacketResponse(StringExtractorGDBRemote &response,
uint64_t fail_result, Status &error)
{
+ // The packet is expected to have the following
@@ -3064,22 +3064,41 @@ static int gdb_errno_to_system(int err) {
static uint64_t ParseHostIOPacketResponse(StringExtractorGDBRemote &response,
uint64_t fail_result, Status &error)
{
+ // The packet is expected to have the following
@@ -3064,22 +3064,41 @@ static int gdb_errno_to_system(int err) {
static uint64_t ParseHostIOPacketResponse(StringExtractorGDBRemote &response,
uint64_t fail_result, Status &error)
{
+ // The packet is expected to have the following
jasonmolenda wrote:
I read through the patch again cleanly, and I don't have any problems with the
PR at this point. The only thing I would note is that in `GetClangTargetABI`
we're constructing a string which indicates which ISA extensions are enabled
(that are relevant here) to return a str
jasonmolenda wrote:
> As for lldb, maybe it can be useful to obtain features flags from `ArchSpec`,
> but I think this should be done in a separate PR, if you don't mind.
Yes, agree with doing this separately so we can get this PR landed.
https://github.com/llvm/llvm-project/pull/99336
___
https://github.com/jasonmolenda approved this pull request.
I don't feel like I am an authoritative owner of the parts being modified by
this PR, but I am fine with this fwiw.
https://github.com/llvm/llvm-project/pull/99336
___
lldb-commits mailing li
https://github.com/jasonmolenda closed
https://github.com/llvm/llvm-project/pull/109611
___
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.
I read through the patch, this looks good to me.
https://github.com/llvm/llvm-project/pull/108365
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailm
jasonmolenda wrote:
> What's the exact situation that triggered these extra packets. Could it be
> simulated from a gdb-remote client test (i.e., by mocking server responses)?
We've always done it when we step over our dynamic loader notification
breakpoint (when new solibs are loaded and lldb
https://github.com/jasonmolenda created
https://github.com/llvm/llvm-project/pull/109611
lldb has two RegisterLocation classes that do slightly different things.
UnwindPlan::Row::RegisterLocation (new: AbstractRegisterLocation) has a
description of how to find a register's value or location, n
https://github.com/jasonmolenda closed
https://github.com/llvm/llvm-project/pull/109499
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Jason Molenda
Date: 2024-09-25T21:36:51-07:00
New Revision: 3d0469516c687b6dad3e6482fd94d64c65fa4a01
URL:
https://github.com/llvm/llvm-project/commit/3d0469516c687b6dad3e6482fd94d64c65fa4a01
DIFF:
https://github.com/llvm/llvm-project/commit/3d0469516c687b6dad3e6482fd94d64c65fa4a01.diff
Author: Jason Molenda
Date: 2024-09-25T21:51:38-07:00
New Revision: 0f984976897857a8f4003063be6fa38a733fa624
URL:
https://github.com/llvm/llvm-project/commit/0f984976897857a8f4003063be6fa38a733fa624
DIFF:
https://github.com/llvm/llvm-project/commit/0f984976897857a8f4003063be6fa38a733fa624.diff
Author: Jason Molenda
Date: 2024-09-24T15:43:34-07:00
New Revision: ce1f01b887ea5945ec3ffb45e05e674804d5d7a7
URL:
https://github.com/llvm/llvm-project/commit/ce1f01b887ea5945ec3ffb45e05e674804d5d7a7
DIFF:
https://github.com/llvm/llvm-project/commit/ce1f01b887ea5945ec3ffb45e05e674804d5d7a7.diff
https://github.com/jasonmolenda created
https://github.com/llvm/llvm-project/pull/109751
The UnwindPlan class has getter and setter methods for specifying an abstract
register location, but it doesn't have a setter for a DWARF Expression register
location. This hasn't been needed for any of t
https://github.com/jasonmolenda closed
https://github.com/llvm/llvm-project/pull/109751
___
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.
Sorry for the delay in reviewing, this looks good to me, thanks for doing this.
https://github.com/llvm/llvm-project/pull/106950
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https
https://github.com/jasonmolenda created
https://github.com/llvm/llvm-project/pull/109499
Some gdb remote serial protocol stubs will send the thread IDs and PCs for all
threads in a process in the stop-reply packet. lldb often needs to know the pc
values for all threads while at a private stop
https://github.com/jasonmolenda closed
https://github.com/llvm/llvm-project/pull/108663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jasonmolenda wrote:
> Feels like we diverted you from your original problem though, which was the
> remote taking the informative errno and changing it to some meaningless value.
It should do that though, shouldn't it? We look up the ERRNO constant we got
in the GDBRemoteErrno table, sending
https://github.com/jasonmolenda created
https://github.com/llvm/llvm-project/pull/110943
If lldb tries to attach to a process that is marked 'Translated' with
debugserver, it will exec the Rosetta debugserver to handle the debug session
without checking if it is present. If there is a configu
https://github.com/jasonmolenda closed
https://github.com/llvm/llvm-project/pull/110965
___
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/110965
The x86 assembly instruction scanner creates incorrect UnwindPlans when a
mid-function epilogue has a non-epilogue instruction in it.
The x86 instruction analysis which creates an UnwindPlan handles mid-fu
https://github.com/jasonmolenda closed
https://github.com/llvm/llvm-project/pull/110646
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jasonmolenda wrote:
Very nice! And now we'll see what all the CI bots think of this change. :)
https://github.com/llvm/llvm-project/pull/110646
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/l
jasonmolenda wrote:
Alex had a PR a month ago https://github.com/llvm/llvm-project/pull/106791 that
got reverted from the same test failing on x86, I tried to repo the failure a
few times on an intel mac and never succeeded. I'll try again with your patch
when I have that set up. If this tes
jasonmolenda wrote:
(wrote that update too quickly while running out the door -- I can run the
lldb-shell tests both with and without your patch, and they pass. I'm not able
to repo the failure the CI bots saw.)
https://github.com/llvm/llvm-project/pull/111409
jasonmolenda wrote:
Updated patch to have a local `symtab_command` structure in ObjectFileMachO
with larger offset fields, and read the load command fields into this
structure. Simplifies the patch; the exiting slide calculations can remain
unmodified now that 64-bit offsets are being used.
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/117832
>From 00a429c14d159ebc42ac7c3a7e98a91851ece236 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Tue, 26 Nov 2024 17:56:06 -0800
Subject: [PATCH 1/2] [lldb][Mach-O] Handle shared cache binaries correctly
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/117832
>From 00a429c14d159ebc42ac7c3a7e98a91851ece236 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Tue, 26 Nov 2024 17:56:06 -0800
Subject: [PATCH 1/3] [lldb][Mach-O] Handle shared cache binaries correctly
jasonmolenda wrote:
> Is changing `struct symtab_command` to have the right-sized fields a no-go?
Yes, this is one possibility, and maybe the best. The current structure
reflects the in-binary layout, so it can be read (with endian fixing) on one go.
https://github.com/llvm/llvm-project/pull/
https://github.com/jasonmolenda closed
https://github.com/llvm/llvm-project/pull/117832
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jasonmolenda wrote:
> Thanks Jason. Looks good. (I think the arm failure is due to it being a
> 32-bit machine. Maybe it would be sufficient to use 32-bit values everywhere?)
I think the fail on the arm bot was because I have a scripted process plugin
and it imports examples/python/templates/s
https://github.com/jasonmolenda approved this pull request.
Sorry for the delay, I read the patch quickly yesterday without reading the
description and was a little confused. Read the description and seeing the
test case, I see what this is doing. Looks good to me. I didn't realize the
disc
Author: Jason Molenda
Date: 2024-11-19T16:01:27-08:00
New Revision: d29a50f358e71a695b23e456d66ed2924617deb9
URL:
https://github.com/llvm/llvm-project/commit/d29a50f358e71a695b23e456d66ed2924617deb9
DIFF:
https://github.com/llvm/llvm-project/commit/d29a50f358e71a695b23e456d66ed2924617deb9.diff
@@ -6184,7 +6184,14 @@ Status Process::GetMemoryRegionInfo(lldb::addr_t
load_addr,
MemoryRegionInfo &range_info) {
if (const lldb::ABISP &abi = GetABI())
load_addr = abi->FixAnyAddress(load_addr);
- return DoGetMemoryRegionInfo(load_a
Author: Jason Molenda
Date: 2024-11-15T00:56:34-08:00
New Revision: fda4a324a384af8dc57cbe0a9b6284c2e8ca073f
URL:
https://github.com/llvm/llvm-project/commit/fda4a324a384af8dc57cbe0a9b6284c2e8ca073f
DIFF:
https://github.com/llvm/llvm-project/commit/fda4a324a384af8dc57cbe0a9b6284c2e8ca073f.diff
https://github.com/jasonmolenda edited
https://github.com/llvm/llvm-project/pull/115963
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jasonmolenda wrote:
I landed a fix with Pavel's suggestion, and rewrote the commit msg to reflect
what the patch now does.
https://github.com/llvm/llvm-project/pull/115963
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.or
https://github.com/jasonmolenda closed
https://github.com/llvm/llvm-project/pull/115963
___
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/115963
>From f8f1d70d1d9eac6d36c0fa84e2a94c032385da39 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Tue, 12 Nov 2024 15:55:15 -0800
Subject: [PATCH 1/6] [lldb] Handle an empty SBMemoryRegionInfo from scripted
https://github.com/jasonmolenda edited
https://github.com/llvm/llvm-project/pull/115382
___
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.
LGTM, simple mechanical update. Apologies for not looking at the earlier PR
for discontiguous range Functions.
https://github.com/llvm/llvm-project/pull/115836
___
lldb-commits mailing list
@@ -288,8 +288,15 @@ Status ScriptedProcess::DoGetMemoryRegionInfo(lldb::addr_t
load_addr,
MemoryRegionInfo ®ion) {
Status error;
if (auto region_or_err =
- GetInterface().GetMemoryRegionContainingAddress(load_addr, er
@@ -407,6 +406,15 @@ CompileUnit *Function::GetCompileUnit() { return
m_comp_unit; }
const CompileUnit *Function::GetCompileUnit() const { return m_comp_unit; }
+Address Function::GetAddress() const {
+ if (m_ranges.empty())
+return Address();
+ // We're using a (DWARF
https://github.com/jasonmolenda edited
https://github.com/llvm/llvm-project/pull/115963
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -288,8 +288,15 @@ Status ScriptedProcess::DoGetMemoryRegionInfo(lldb::addr_t
load_addr,
MemoryRegionInfo ®ion) {
Status error;
if (auto region_or_err =
- GetInterface().GetMemoryRegionContainingAddress(load_addr, er
https://github.com/jasonmolenda edited
https://github.com/llvm/llvm-project/pull/115963
___
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/115963
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -288,8 +288,15 @@ Status ScriptedProcess::DoGetMemoryRegionInfo(lldb::addr_t
load_addr,
MemoryRegionInfo ®ion) {
Status error;
if (auto region_or_err =
- GetInterface().GetMemoryRegionContainingAddress(load_addr, er
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/115963
>From f8f1d70d1d9eac6d36c0fa84e2a94c032385da39 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Tue, 12 Nov 2024 15:55:15 -0800
Subject: [PATCH 1/5] [lldb] Handle an empty SBMemoryRegionInfo from scripted
https://github.com/jasonmolenda created
https://github.com/llvm/llvm-project/pull/117832
The Mach-O load commands have an LC_SYMTAB / struct symtab_command which
represents the offset of the symbol table (nlist records) and string table for
this binary. In a mach-o binary on disk, these are f
jasonmolenda wrote:
I have two criticisms of the patch as-is. We read the LC_SYMTAB load command
into `symtab_load_command` which has six fields, the first two being the usual
`cmd` and `cmdsize`. We use all of the next four: `ncmds`, `strsize`,
`symoff`, `stroff`. I'm taking the uses of tw
Author: Jason Molenda
Date: 2024-11-26T17:00:35-08:00
New Revision: f2129ca94c47875b5f915abc9d7dfb02a7445fe6
URL:
https://github.com/llvm/llvm-project/commit/f2129ca94c47875b5f915abc9d7dfb02a7445fe6
DIFF:
https://github.com/llvm/llvm-project/commit/f2129ca94c47875b5f915abc9d7dfb02a7445fe6.diff
@@ -157,6 +157,12 @@ let Definition = "target" in {
DefaultEnumValue<"eX86DisFlavorDefault">,
EnumValues<"OptionEnumValues(g_x86_dis_flavor_value_types)">,
Desc<"The default disassembly flavor to use for x86 or x86-64 targets.">;
+ def DisassemblyCPU: Property<"dis
https://github.com/jasonmolenda approved this pull request.
This looks reasonable to me.
https://github.com/llvm/llvm-project/pull/117996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-com
https://github.com/jasonmolenda created
https://github.com/llvm/llvm-project/pull/119171
The Apple M4 line of cores includes the Scalable Matrix Extension (SME)
feature. The M4s do not implement Scalable Vector Extension (SVE), although the
processor is in Streaming SVE Mode when the SME is be
https://github.com/jasonmolenda edited
https://github.com/llvm/llvm-project/pull/119171
___
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/119171
___
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/119171
>From 2e3738eb7ed356fe4f9ee24a31af55a01b18bd08 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Sun, 8 Dec 2024 22:21:22 -0800
Subject: [PATCH 1/2] [lldb][debugserver] Read/write SME registers on arm64
T
jasonmolenda wrote:
One difference from debugserver and lldb-server is that lldb-server provides
"vg" and "svg" registers (vector granule, streaming vector granule, depending
on Streaming mode) which is the vector length in 8-byte granules. On Darwin,
debugserver provides only "svl", in bytes
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/119171
>From 2e3738eb7ed356fe4f9ee24a31af55a01b18bd08 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Sun, 8 Dec 2024 22:21:22 -0800
Subject: [PATCH 1/3] [lldb][debugserver] Read/write SME registers on arm64
T
@@ -0,0 +1,111 @@
+/// BUILT with
+///xcrun -sdk macosx.internal clang -mcpu=apple-m4 -g sme.c -o sme
+
+#include
+#include
+#include
+
+void write_sve_regs() {
+ asm volatile("ptrue p0.b\n\t");
+ asm volatile("ptrue p1.h\n\t");
+ asm volatile("ptrue p2.s\n\t");
+ asm
@@ -0,0 +1,163 @@
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+import lldbsuite.test.lldbutil as lldbutil
+import os
+
+
+class TestSMERegistersDarwin(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+mydir = TestBase.compute_mydir
@@ -0,0 +1,163 @@
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+import lldbsuite.test.lldbutil as lldbutil
+import os
+
+
+class TestSMERegistersDarwin(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+mydir = TestBase.compute_mydir
@@ -312,16 +312,21 @@ struct DNBRegisterValue {
uint64_t uint64;
float float32;
double float64;
-int8_t v_sint8[64];
-int16_t v_sint16[32];
-int32_t v_sint32[16];
-int64_t v_sint64[8];
-uint8_t v_uint8[64];
-uint16_t v_uint16[32];
-uint32
@@ -93,6 +93,55 @@ DNBArchMachARM64::SoftwareBreakpointOpcode(nub_size_t
byte_size) {
uint32_t DNBArchMachARM64::GetCPUType() { return CPU_TYPE_ARM64; }
+static std::once_flag g_cpu_has_sme_once;
+bool DNBArchMachARM64::CPUHasSME() {
+ static bool g_has_sme = false;
+ std:
@@ -2387,6 +2863,36 @@ bool DNBArchMachARM64::SetRegisterValue(uint32_t set,
uint32_t reg,
}
break;
+case e_regSetSVE:
+ if (reg >= sve_z0 && reg <= sve_z31) {
+uint16_t max_svl_bytes = GetSMEMaxSVL();
+memcpy(&m_state.context.sve.z[reg -
https://github.com/jasonmolenda created
https://github.com/llvm/llvm-project/pull/121380
The Intel Darwin CI bots had their Xcode updated, which brought in a
debugserver with Brendan Shanks' change from September
7281e0cb3bbcce396aab8b3ea0967d7a17cd287a
https://github.com/llvm/llvm-project/pul
1501 - 1600 of 1925 matches
Mail list logo
