On 5/12/22 12:39, Thomas Gleixner wrote: >> It's OK for a debugging build that runs on one kind of hardware. But, >> if we want LAM-using binaries to be portable, we have to do something >> different. >> >> One of the stated reasons for adding LAM hardware is that folks want to >> use sanitizers outside of debugging environments. To me, that means >> that LAM is something that the same binary might run with or without. > On/off yes, but is there an actual use case where such a mechanism would > at start time dynamically chose the number of bits? I'd love to hear from folks doing the userspace side of this. Will userspace be saying: "Give me all the bits you can!". Or, will it really just be looking for 6 bits only, and it doesn't care whether it gets 6 or 15, it will use only 6? Do the sanitizers have more overhead with more bits? Or *less* overhead because they can store more metadata in the pointers? Will anyone care about the difference about potentially missing 1/64 issues with U57 versus 1/32768 with U48?
