Reland "[lldb] Add template method for getting const or mutable regs from DynamicRegisterInfo (#71402)"

This reverts commit 75b195cc4cee8d6f3216b7602f8247f5888a47af.

I've moved the specialisations

Reland "[lldb] Add template method for getting const or mutable regs from DynamicRegisterInfo (#71402)"

This reverts commit 75b195cc4cee8d6f3216b7602f8247f5888a47af.

I've moved the specialisations out of the class to fix the g++ compilation.

show more ...

Revert "[lldb] Add template method for getting const or mutable regs from DynamicRegisterInfo (#71402)"

This reverts commit 4989c62b318229bff2643c244ebbd03c20e2f781 as it fails to build with g++.

[lldb] Add template method for getting const or mutable regs from DynamicRegisterInfo (#71402)

GDBRemoteRegisterContext only needs to iterate them, ArchitectureAArch64
needs to mutate them if scala

[lldb] Add template method for getting const or mutable regs from DynamicRegisterInfo (#71402)

GDBRemoteRegisterContext only needs to iterate them, ArchitectureAArch64
needs to mutate them if scalable registers change size.

show more ...

[lldb][AArch64] Move register info reconfigure into architecture plugin (#70950)

This removes AArch64 specific code from the GDB* classes.

To do this I've added 2 new methods to Architecture:
*

[lldb][AArch64] Move register info reconfigure into architecture plugin (#70950)

This removes AArch64 specific code from the GDB* classes.

To do this I've added 2 new methods to Architecture:
* RegisterWriteCausesReconfigure to check if what you are about to do
will trash the register info.
* ReconfigureRegisterInfo to do the reconfiguring. This tells you if
anything changed so that we only invalidate registers when needed.

So that ProcessGDBRemote can call ReconfigureRegisterInfo in
SetThreadStopInfo,
I've added forwarding calls to GDBRemoteRegisterContext and the base
class
RegisterContext.

(which removes a slightly sketchy static cast as well)

RegisterContext defaults to doing nothing for both the methods
so anything other than GDBRemoteRegisterContext will do nothing.

show more ...

[lldb][AArch64] Simplify handing of scalable registers using vg and svg (#70914)

This removes explicit invalidation of vg and svg that was done in
`GDBRemoteRegisterContext::AArch64Reconfigure`. Th

[lldb][AArch64] Simplify handing of scalable registers using vg and svg (#70914)

This removes explicit invalidation of vg and svg that was done in
`GDBRemoteRegisterContext::AArch64Reconfigure`. This was in fact
covering up a bug elsehwere.

Register information says that a write to vg also invalidates svg (it
does not unless you are in streaming mode, but we decided to keep it
simple and say it always does).

This invalidation was not being applied until *after* AArch64Reconfigure
was called. This meant that without those manual invalidates this
happened:
* vg is written
* svg is not invalidated
* Reconfigure uses the written vg value
* Reconfigure uses the *old* svg value

I have moved the AArch64Reconfigure call to after we've processed the
invalidations caused by the register write, so we no longer need the
manual invalidates in AArch64Reconfigure.

In addition I have changed the order in which expedited registers as
parsed. These registers come with a stop notification and include,
amongst others, vg and svg.

So now we:
* Parse them and update register values (including vg and svg)
* AArch64Reconfigure, which uses those values, and invalidates every
register, because offsets may have changed.
* Parse the expedited registers again, knowing that none of the values
will have changed due to the scaling.

This means we use the expedited registers during the reconfigure, but
the invalidate does not mean we throw all of them away.

The cost is we parse them twice client side, but this is cheap compared
to a network packet, and is limited to AArch64 targets only.

On a system with SVE and SME, these are the packets sent for a step:
```
(lldb) b-remote.async> < 803> read packet:
$T05thread:p1f80.1f80;name:main.o;threads:1f80;thread-pcs:000000000040056c<...>a1:0800000000000000;d9:0400000000000000;reason:trace;#fc
intern-state < 21> send packet: $xfffffffff200,200#5e
intern-state < 516> read packet:
$e4f2ffffffff000000<...>#71
intern-state < 15> send packet: $Z0,400568,4#4d
intern-state < 6> read packet: $OK#9a
dbg.evt-handler < 16> send packet: $jThreadsInfo#c1
dbg.evt-handler < 224> read packet:
$[{"name":"main.o","reason":"trace","registers":{"161":"0800000000000000",<...>}],"signal":5,"tid":8064}]]#73
```

You can see there are no extra register reads which means we're using
the expedited registers.

For a write to vg:
```
(lldb) register write vg 4
lldb < 37> send packet:
$Pa1=0400000000000000;thread:1f80;#4a
lldb < 6> read packet: $OK#9a
lldb < 20> send packet: $pa1;thread:1f80;#29
lldb < 20> read packet: $0400000000000000#04
lldb < 20> send packet: $pd9;thread:1f80;#34
lldb < 20> read packet: $0400000000000000#04
```

There is the initial P write, and lldb correctly assumes that SVG is
invalidated by this also so we read back the new vg and svg values
afterwards.

show more ...

Reland "[lldb][AArch64] Invalidate SVG prior to reconfiguring ZA regdef (#66768)""

This reverts commit 8d80a452b841a211e0f3bce01a01c9a015d287f3.

The pointer to the invalidates lists needs to be non

Reland "[lldb][AArch64] Invalidate SVG prior to reconfiguring ZA regdef (#66768)""

This reverts commit 8d80a452b841a211e0f3bce01a01c9a015d287f3.

The pointer to the invalidates lists needs to be non-const. Though in this case
I don't think it's ever modified.

Also I realised that the invalidate list was being set on svg not vg.
Should be the other way around.

show more ...

Revert "[lldb][AArch64] Invalidate SVG prior to reconfiguring ZA regdef (#66768)"

This reverts commit f2c09e5e16d592303b5a1c158cdef28ef08104f0, due to compilation
failures on buildbots.

[lldb][AArch64] Invalidate SVG prior to reconfiguring ZA regdef (#66768)

This fixes a bug where writing vg during streaming mode
could prevent you reading za directly afterwards.

vg is invalidat

[lldb][AArch64] Invalidate SVG prior to reconfiguring ZA regdef (#66768)

This fixes a bug where writing vg during streaming mode
could prevent you reading za directly afterwards.

vg is invalidated just prior to us reading it in AArch64Reconfigure,
but svg was not. This lead to some situations where vg would be
updated or cleared and re-read, but svg would not be.

This meant it had some undefined value which lead to errors
that prevented us reading ZA. Likely we received a lot more
data than we were expecting.

There are at least 2 ways to get into this situation:
* Explicit write by the user to vg.
* We have just stopped and need to get the potentially new svg and vg.

The first is handled by invalidating svg client side before fetching the
new one. This also
covers some but not all of the second scenario. For the second, I've
made writes to vg
invalidate svg by noting this in the register information.

Whichever one of those kicks in, we'll get the latest value of svg.

The bug may depend on timing, I could not find a consistent way
to trigger it. I originally found it when checking whether za
is disabled after a vg change, so I've added checks for that
to TestZAThreadedDynamic.

The SVE VG version of the bug did show up on the buildbot,
but not consistently. So it's possible that TestZAThreadedDynamic
does in fact cover this, but I haven't run it enough times to know.

show more ...

[lldb][AArch64] Invalidate cached VG value before reconfiguring SVE registers

This fixes 46b961f36bc5b1105356d1701f0c7c9d439be9c8.

Prior to the SME changes the steps were:
* Invalidate all register

[lldb][AArch64] Invalidate cached VG value before reconfiguring SVE registers

This fixes 46b961f36bc5b1105356d1701f0c7c9d439be9c8.

Prior to the SME changes the steps were:
* Invalidate all registers.
* Update value of VG and use that to reconfigure the registers.
* Invalidate all registers again.

With the changes for SME I removed the initial invalidate thinking
that it didn't make sense to do if we were going to invalidate them
all anyway after reconfiguring.

Well the reason it made sense was that it forced us to get the
latest value of vg which we needed to reconfigure properly.

Not doing so caused a test failure on our Graviton bot which has SVE
(https://lab.llvm.org/buildbot/#/builders/96/builds/45722). It was
flaky and looping it locally would always fail within a few minutes.
Presumably it was using an invalid value of vg, which caused some offsets
to be calculated incorrectly.

To fix this I've invalided vg in AArch64Reconfigure just before we read
it. This is the same as the fix I have in review for SME's svg register.

Pushing this directly to fix the ongoing test failure.

show more ...

[lldb][AArch64] Implement resizing of SME's ZA register

The size of ZA depends on the streaming vector length regardless
of the active mode. So in addition to vg (which reports the active
mode) we m

[lldb][AArch64] Implement resizing of SME's ZA register

The size of ZA depends on the streaming vector length regardless
of the active mode. So in addition to vg (which reports the active
mode) we must send the client svg.

Otherwise the mechanics are the same as for non-streaming SVE.
Use the svg value to update the defined size of ZA, accounting
for the fact that ZA is not a single vector but a suqare matrix.

So if svg is 8, a single streaming vector would be 8*8 = 64 bytes.
ZA is that squared, so 64*64 = 4096 bytes.

Testing is included in a later patch.

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D159504

show more ...

[lldb][AArch64] Remove bool return from UpdateARM64SVERegistersInfos

This always succeeds. While I'm here, document why we check the size
of p0 against the value of VG.

Reviewed By: omjavaid

Diffe

[lldb][AArch64] Remove bool return from UpdateARM64SVERegistersInfos

This always succeeds. While I'm here, document why we check the size
of p0 against the value of VG.

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D157845

show more ...

Add a generic Process method to dump plugin history.

I need to call this to figure out why the assert in
StopInfoMachException::CreateStopReasonWithMachException is triggering, but
it isn't appropri

Add a generic Process method to dump plugin history.

I need to call this to figure out why the assert in
StopInfoMachException::CreateStopReasonWithMachException is triggering, but
it isn't appropriate to directly access the GDBRemoteCommunication there. And
dumping whatever history the process plugin has collected during the run isn't
gdb-remote specific...

Differential Revision: https://reviews.llvm.org/D154992

show more ...

[LLDB] Pass const RegisterInfo& to RegisterValue::SetValueFromData

Familiar story, callers are either checking upfront that the pointer
wasn't null or not checking at all. SetValueFromData itself di

[LLDB] Pass const RegisterInfo& to RegisterValue::SetValueFromData

Familiar story, callers are either checking upfront that the pointer
wasn't null or not checking at all. SetValueFromData itself didn't
check either.

So make the parameter a ref and fixup the few places where a nullptr
check seems needed.

Depends on D135668

Reviewed By: clayborg

Differential Revision: https://reviews.llvm.org/D135670

show more ...

[LLDB] Change RegisterValue::SetFromMemoryData to const RegisterInfo&

All callers were either assuming their pointer was not null before calling
this, or checking beforehand.

Reviewed By: clayborg

[LLDB] Change RegisterValue::SetFromMemoryData to const RegisterInfo&

All callers were either assuming their pointer was not null before calling
this, or checking beforehand.

Reviewed By: clayborg

Differential Revision: https://reviews.llvm.org/D135668

show more ...

[lldb] Refactor DataBuffer so we can map files as read-only

Currently, all data buffers are assumed to be writable. This is a
problem on macOS where it's not allowed to load unsigned binaries in
mem

[lldb] Refactor DataBuffer so we can map files as read-only

Currently, all data buffers are assumed to be writable. This is a
problem on macOS where it's not allowed to load unsigned binaries in
memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and
MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our
platform.

Binaries are mapped through FileSystem::CreateDataBuffer which returns a
DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer
because every DataBuffer in LLDB is considered to be writable. In order
to use a read-only llvm::MemoryBuffer I had to split our abstraction
around it.

This patch distinguishes between a DataBuffer (read-only) and
WritableDataBuffer (read-write) and updates LLDB to use the appropriate
one.

rdar://74890607

Differential revision: https://reviews.llvm.org/D122856

show more ...

[lldb] Convert ProcessGDBRemoteLog to the new API

[lldb] [gdb-remote] Remove HardcodeARMRegisters() hack

HardcodeARMRegisters() is a hack that was supposed to be used "until
we can get an updated debugserver down on the devices". Since it was
intr

[lldb] [gdb-remote] Remove HardcodeARMRegisters() hack

HardcodeARMRegisters() is a hack that was supposed to be used "until
we can get an updated debugserver down on the devices". Since it was
introduced back in 2012, there is a good chance that the debugserver
has been updated at least once since then. Removing this code makes
transition to the new DynamicRegisterInfo API easier.

Differential Revision: https://reviews.llvm.org/D111491

show more ...

[lldb] [ABI/X86] Support combining xmm* and ymm*h regs into ymm*

gdbserver does not expose combined ymm* registers but rather XSAVE-style
split xmm* and ymm*h portions. Extend value_regs to support

[lldb] [ABI/X86] Support combining xmm* and ymm*h regs into ymm*

gdbserver does not expose combined ymm* registers but rather XSAVE-style
split xmm* and ymm*h portions. Extend value_regs to support combining
multiple registers and use it to create user-friendly ymm* registers
that are combined from split xmm* and ymm*h portions.

Differential Revision: https://reviews.llvm.org/D108937

show more ...

Revert "[lldb] [ABI/X86] Support combining xmm* and ymm*h regs into ymm*"

This reverts commit 5352ea4a721ef252129994111b83dc350ecc71da. It seems
to have broken the arm buildbot.

[lldb] [ABI/X86] Support combining xmm* and ymm*h regs into ymm*

gdbserver does not expose combined ymm* registers but rather XSAVE-style
split xmm* and ymm*h portions. Extend value_regs to support

[lldb] [ABI/X86] Support combining xmm* and ymm*h regs into ymm*

gdbserver does not expose combined ymm* registers but rather XSAVE-style
split xmm* and ymm*h portions. Extend value_regs to support combining
multiple registers and use it to create user-friendly ymm* registers
that are combined from split xmm* and ymm*h portions.

Differential Revision: https://reviews.llvm.org/D108937

show more ...

[lldb] [DynamicRegisterInfo] Support iterating over registers()

Add DynamicRegisterInfo::registers() method that returns
llvm::iterator_range<> over RegisterInfos. This is a convenient
replacement

[lldb] [DynamicRegisterInfo] Support iterating over registers()

Add DynamicRegisterInfo::registers() method that returns
llvm::iterator_range<> over RegisterInfos. This is a convenient
replacement for GetNumRegisters() + GetRegisterInfoAtIndex().

Differential Revision: https://reviews.llvm.org/D111136

show more ...

Recommit: [lldb] Remove "dwarf dynamic register size expressions" from RegisterInfo

The previous version of the patch did not update the definitions in
conditionally compiled code. This patch includ

Recommit: [lldb] Remove "dwarf dynamic register size expressions" from RegisterInfo

The previous version of the patch did not update the definitions in
conditionally compiled code. This patch includes changes to ARC and
windows targets.

Original commit message was:

These were added to support some mips registers on linux, but linux mips
support has now been removed due.

They are still referenced in the freebds mips implementation, but the
completeness of that implementation is also unknown. All other
architectures just set these fields to zero, which is a cause of
significant bloat in our register info definitions.

Arm also has registers with variable sizes, but they were implemented in
a more gdb-compatible fashion and don't use this feature.

Differential Revision: https://reviews.llvm.org/D110914

show more ...

Revert "[lldb] Remove "dwarf dynamic register size expressions" from RegisterInfo"

This reverts commit 00e704bf080ffeeb9e334fb3ab71594f9aa50969.

This commit should should have updated
llvm/llvm-pro

Revert "[lldb] Remove "dwarf dynamic register size expressions" from RegisterInfo"

This reverts commit 00e704bf080ffeeb9e334fb3ab71594f9aa50969.

This commit should should have updated
llvm/llvm-project/lldb/source/Plugins/ABI/ARC/ABISysV_arc.cpp like the other
architectures.

show more ...

[lldb] Remove "dwarf dynamic register size expressions" from RegisterInfo

These were added to support some mips registers on linux, but linux mips
support has now been removed due.

They are still r

[lldb] Remove "dwarf dynamic register size expressions" from RegisterInfo

These were added to support some mips registers on linux, but linux mips
support has now been removed due.

They are still referenced in the freebds mips implementation, but the
completeness of that implementation is also unknown. All other
architectures just set these fields to zero, which is a cause of
significant bloat in our register info definitions.

Arm also has registers with variable sizes, but they were implemented in
a more gdb-compatible fashion and don't use this feature.

Differential Revision: https://reviews.llvm.org/D110914

show more ...

[lldb] [gdb-remote] Use local regnos for value_regs/invalidate_regs

Switch the gdb-remote client logic to use local (LLDB) register numbers
in value_regs/invalidate_regs rather than remote regnos. T

[lldb] [gdb-remote] Use local regnos for value_regs/invalidate_regs

Switch the gdb-remote client logic to use local (LLDB) register numbers
in value_regs/invalidate_regs rather than remote regnos. This involves
translating regnos received from lldb-server.

Differential Revision: https://reviews.llvm.org/D110027

show more ...