On Mon, Jan 16, 2017 at 03:47:55PM +0000, Pedro Alves wrote: > On 01/16/2017 03:11 PM, Yao Qi wrote: > > > >> > > >> > gdb must already re-detect the vector length on stop, since the target > >> > could have called the prctl() in the meantime. > > Yes, gdb assumes the vector length may be changed, so it re-detects on > > every stop, but I don't see the need for gdb to change the vector length. > > > > Do we need to consider inferior function calls here? > > Say the program is stopped in code that assumes "vector length N", and > the user does "print some_function_that_assumes_some_other_vector_length ()". > > Is that a use case we need to cover? > > If so, to make it work correctly, the debugger needs to be able to change the > vector length to the length assumed by that called function, and then > restore it back after the call completes (or is aborted). > > I have no idea whether the debugger will be able to figure > out a function's assumed vector length from debug info or some such. I think the proposed ptrace interface can support this -- i.e., it should provide everything needed to save off the VL and register state, switch VL, do something else, then restore the VL and state (if not, that's a bug). My current position is that determining what vector length is required by what function or binary is a 100% userspace problem, though. ELF/DWARF could have annotations about this, though it wouldn't necessarily be per-function -- you might require a whole image to be built for the same vector length (if any). Cheers ---Dave -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
