ayushsahay1837 wrote: Thanks for reviewing this, David!
> Our intention is to provide support in this PR for all the standard CSRs, and > in a later PR for the CSRs in the Xqci extension, and use that as an example > for others to implement their own extensions. The named CSRs in this PR are limited to those listed in _Table 4 (Currently allocated RISC-V unprivileged CSR addresses)_ of [_the RISC-V Instruction Set Manual (Volume II)_](https://drive.google.com/file/d/17GeetSnT5wW3xNuAHI95-SI1gPGd5sJ_/view). Qualcomm is in the process of upstreaming implementations of _Xqci_. We'll be looking to include named CSRs therein in the future. > These should be gated by some discovery mechanism, like ELF attributes, since > we don't want to collide if 2 extensions use, say, CSR 50. This corresponds to the third phase listed [here](https://discourse.llvm.org/t/add-risc-v-csrs-to-core-dumps/84348/6). > The existing riscv-32 is static. I think we'll need to replace that (and the > 64 bit static implementation, to add CSR support) with dynamic. Downstream we > have only dynamic in our 20.0 release. IIUC, then the existing support for the postmortem debug of 32-bit RISC-V core dump images looks to facilitate the enablement/disablement of optional register sets in their entirety; it doesn't support handling subsets of register sets. This change looks to provision support for handling subsets of register sets in addition to handling entire register sets. > Can we share the two implementations? We've tweaked the existing implementation to facilitate the coexistence of both the schemes. However, the implementation proposed in this PR switches to building register information for GPRs, FPRs, and CSRs dynamically unconditionally, rendering the existing scheme unexercised. > Also, test cases? As Ted has mentioned, we're working on devising/procuring a test that we could upstream. I just thought that it'll be good to get the community's initial thoughts on the proposed scheme in the meanwhile. > Also we need a comment somewhere, I suggest in this PR's description for now, > that describes the note's format in detail. > I agree - we should publish a comment with the note's format. I think a > comment in the sources would be a more natural place to look than the commit > message. Sure, I'll add a description of the note's format to the source, and post it here as well. https://github.com/llvm/llvm-project/pull/142932 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
