probinson added a comment. In D69393#1720816 <https://reviews.llvm.org/D69393#1720816>, @ast wrote:
> > The address spaces envisioned by the Linux kernel appear to be more > > informational and not descriptive of hardware characteristics. > > From the kernel pov the `__user` and normal are two different address spaces > that must be accessed via different kernel primitives. > User access needs stac/clac on x86 and other precautions. > iirc other architectures have co-processor address space that needs its own > load/store equivalents. > `__percpu` is also different address space. It's roughly equivalent to > `__thread` in user space. Ah, it has been so long since I worked on priv code that I had forgotten about the use of user-context access instructions. That would be a reasonable use of the DW_AT_address_class attribute for kernel code, so that a kernel-mode debugger would do the right thing with user-space addresses. In D69393#1720817 <https://reviews.llvm.org/D69393#1720817>, @yonghong-song wrote: > @probinson Thanks for the input! That is my concern too mixing the user > defined and language defined may not be a good idea and may actually cause > confusion. This is exactly this RFC for. Let us try a different dwarf > encoding and then we can continue to discuss. For proper separation of concerns, it would be best to define values to use for the DWARF attribute independently of whatever conventions the Linux kernel might have. What the debugger needs to know is how to dereference the pointers; this may be different than how the kernel chooses to classify addresses. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69393/new/ https://reviews.llvm.org/D69393 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
