[Lldb-commits] [PATCH] D128612: RISC-V big-endian support implementation

jrtc27 added inline comments. Comment at: clang/lib/Basic/Targets/RISCV.h:113 +if (Triple.isLittleEndian()) + resetDataLayout("e-m:e-p:32:32-i64:64-n32-S128"); +else And please avoid repeating the whole data layout, just make the e/E a variable

[Lldb-commits] [PATCH] D110914: [lldb] Remove "dwarf dynamic register size expressions" from RegisterInfo

jrtc27 added a comment. In D110914#3036085 , @labath wrote: > In D110914#3036079 , @jrtc27 wrote: > >> Is this removing this going to be a problem for RISC-V, where the >> floating-point registers could be

[Lldb-commits] [PATCH] D110914: [lldb] Remove "dwarf dynamic register size expressions" from RegisterInfo

jrtc27 added a comment. Is this removing this going to be a problem for RISC-V, where the floating-point registers could be 32-bit or 64-bit (or 128-bit in future), depending on which extensions you have? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[Lldb-commits] [PATCH] D62732: [RISCV] Add SystemV ABI

jrtc27 added a comment. In D62732#2995111 , @MaskRay wrote: > Hi Luís, is this still needed after D86292 ? > Or are there missing pieces? > @felixonmars reported that https://archriscv.felixc.at/.status/logs/lldb.log >

[Lldb-commits] [PATCH] D105182: [lldb] Add "memory tag write" command

jrtc27 added a comment. In D105182#2930795 , @DavidSpickett wrote: >> Many different types of memory tagging exist, MTE is but one. > > Sure. I'm not opposed to making changes to adapt to the properties of > different tags. However the most concrete

[Lldb-commits] [PATCH] D105182: [lldb] Add "memory tag write" command

jrtc27 added a comment. I'm concerned by the generality of the command "memory tag". Many different types of memory tagging exist, MTE is but one. CHERI uses memory tagging for something completely different (tracking valid capability, ie pointer provenance), and its tags make sense to read

[Lldb-commits] [PATCH] D62732: [RISCV] Add SystemV ABI

jrtc27 added inline comments. Comment at: lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp:118 + + // Previous frames pc is in ra + row->SetRegisterLocationToRegister(pc_reg_num, ra_reg_num, true); Comment at:

[Lldb-commits] [PATCH] D101462: [MC] Untangle MCContext and MCObjectFileInfo

jrtc27 added a comment. In D101462#2739404 , @MaskRay wrote: > In D101462#2733726 , @flip1995 > wrote: > >>> I'll keep this open for a few days as it touches too many things. >> >> Sounds good  >> >>> but

[Lldb-commits] [PATCH] D101462: Make it possible for targets to define their own MCObjectFileInfo

jrtc27 added a comment. Herald added a subscriber: JDevlieghere. What's the benefit of less-aligned functions? Is that not more likely to get poor performance due to cache line straddling of the first instruction? Regardless, the functional change should be separated out from the refactoring.

[Lldb-commits] [PATCH] D96766: [lldb] [Process/FreeBSD] Introduce mips64 FPU reg support

jrtc27 added inline comments. Comment at: lldb/source/Plugins/Process/Utility/RegisterContextFreeBSD_mips64.cpp:141 + uint64_t f31; + uint64_t fcsr; + uint64_t fir; MIPS calls it FCSR, FreeBSD's regnum.h calls it FSR. I don't know which is the right thing

[Lldb-commits] [PATCH] D95947: [lldb] [Process/FreeBSDRemote] Introduce powerpc support

jrtc27 accepted this revision. jrtc27 added a comment. In D95947#2549599 , @mgorny wrote: > @jrtc27 , does this look good? Yep, assuming it still works. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D95947/new/ https://reviews.llvm.org/D95947

[Lldb-commits] [PATCH] D95947: [lldb] [Process/FreeBSDRemote] Introduce powerpc support

jrtc27 added inline comments. Comment at: lldb/source/Host/common/NativeProcessProtocol.cpp:525-526 static const uint8_t g_s390x_opcode[] = {0x00, 0x01}; + static const uint8_t g_ppc_opcode[] = {0x7f, 0xc0, 0x00, 0x08}; static const uint8_t g_ppc64le_opcode[] = {0x08,

[Lldb-commits] [PATCH] D95947: [lldb] [Process/FreeBSDRemote] Introduce powerpc support

jrtc27 added inline comments. Comment at: lldb/source/Host/common/NativeProcessProtocol.cpp:525-526 static const uint8_t g_s390x_opcode[] = {0x00, 0x01}; + static const uint8_t g_ppc_opcode[] = {0x7f, 0xc0, 0x00, 0x08}; static const uint8_t g_ppc64le_opcode[] = {0x08,

[Lldb-commits] [PATCH] D95947: [lldb] [Process/FreeBSDRemote] Introduce powerpc support

jrtc27 added inline comments. Comment at: lldb/source/Host/common/NativeProcessProtocol.cpp:525-526 static const uint8_t g_s390x_opcode[] = {0x00, 0x01}; + static const uint8_t g_ppc_opcode[] = {0x7f, 0xc0, 0x00, 0x08}; static const uint8_t g_ppc64le_opcode[] = {0x08,

[Lldb-commits] [PATCH] D95947: [lldb] [Process/FreeBSDRemote] Introduce powerpc support

jrtc27 added inline comments. Comment at: lldb/source/Host/common/NativeProcessProtocol.cpp:525-526 static const uint8_t g_s390x_opcode[] = {0x00, 0x01}; + static const uint8_t g_ppc_opcode[] = {0x7f, 0xc0, 0x00, 0x08}; static const uint8_t g_ppc64le_opcode[] = {0x08,

[Lldb-commits] [PATCH] D86292: [LLDB][RISCV] Distinguish between riscv32 and riscv64 based on ELF class

jrtc27 added a comment. Not so silly; gdb (well, the names are inherited from bfd) has `set architecture riscv:rv32`/`set architecture riscv:rv64` :) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86292/new/ https://reviews.llvm.org/D86292

[Lldb-commits] [PATCH] D62732: [RISCV] Add SystemV ABI

jrtc27 added a comment. Yeah, I don't think we want to be merging code we can't test even in a non-automated way. Even if this code is completely bug-free, the inability to test it just means we risk having it bit-rot with nobody noticing. Repository: rG LLVM Github Monorepo CHANGES SINCE