tedwoodward wrote: > I'll leave the proper review to the RISC-V interested parties, just some high > level points: > > * The csrs that have names, are all the ones here from the RISC-V > standard? Do they include any names allocated for custom extensions or do you > plan to do anything like that? (I assume custom extensions can also make use > of some csr space, but you could just make people type the generic name for > these). > > * LLDB's design is unfortunately forcing you to enumerate everything up > front, I doubt there's much we can do about that without refactoring the > others. In some places you might be able to consteveal something, but it > probably works out the same if not more in compile time. > > * You have this riscv-32-dynamic now, is the existing riscv-32 just the > dynamic one with no extra registers, can we share the two implementations? > > * You're treating bare metal core files as if they are Linux, I would > like to know if Linux cores themselves work and how far we are from > supporting those. This will become a popular use case. You can raise an issue > with what you find, I'm not expecting you to do the work.
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. 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. 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. We don't have a running Linux, so I can't comment on "real" Linux core files. In theory, they're the same, but you know about theory vs practice... > Also, test cases? > > I already let one RISC-V core file patch go in without test cases, I'm not > happy about another. > > If you want to know how to make them, some way that documents the format of > the note at the same time would be great. If you were able to yaml2obj > perhaps. > > (because otherwise the C++ code is the only documentation) > > Maybe Python could be used to generate YAML of various sparse or not sparse > notes and substitute those into a template for testing. I'm currently negotiating with our users on this. Like @JDevlieghere , I can't publish a core dump with internal code in it. But if I can learn how to dump core with an arbitrary testcase, then I can make a core file to load and test. We'll see. > Also we need a comment somewhere, I suggest in this PR's description for now, > that describes the note's format in detail. It will also help review. > > (as there's no natural place for it, if the Linux kernel was generating them, > it'd go there, but bare metal, could be anyone generating them) 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. 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
