labath added inline comments.
================
Comment at:
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp:82-106
+uint32_t
+RegisterContextCorePOSIX_arm64::CalculateSVEOffset(uint32_t reg_num) const {
+ uint32_t sve_offset = 0;
+ if (m_sve_state == SVE_STATE::SVE_STATE_FPSIMD) {
+ if (IsSVEZ(reg_num))
+ sve_offset = (reg_num - GetRegNumSVEZ0()) * 16;
+ else if (reg_num == GetRegNumFPSR())
----------------
omjavaid wrote:
> labath wrote:
> > I'm confused by this function. If I understant the SVE_PT macros and the
> > logic in `RegisterInfoPOSIX_arm64::ConfigureVectorRegisterInfos` correctly,
> > then they both seem to encode the same information. And it seems to me that
> > this function should just be `reg_infos[reg_num].offset - some_constant`,
> > which is the same thing that we're doing for the arm FP registers when SVE
> > is disabled, and also for most other architectures too.
> >
> > Why is that not the case? Am I missing something? If they are not encoding
> > the same thing, could they be made to encode the same thing?
> This function calculates offset of a particular register in core note data.
> SVE data in core dump is similar to what PTrace emits and offsets into this
> data is not linear. SVE macros are used to access those offsets based on
> register numbers and currently selected vector length.
> Also for the purpose of ease we have linear offsets in SVE register infos and
> it helps us simplify register data once it makes way to
> GDBRemoteRegisterContext on the client side.
Could you give an example of the non-linearity of the core dump data? (Some
registers, and their respective core file and gdb-remote offsets)
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D77047/new/
https://reviews.llvm.org/D77047
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
