You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the discussion for #6544@derekbruening and @abhinav92003 raised the issue of applications which change the vector length at runtime. Currently DynamoRIO assumes that the VL doesn't change at run time, but it is possible that applications can do it anyway using the Linux prctl() system call.
Generally, we want to be able to run any program that the hardware supports, not just those that follow software conventions in compilers or ABIs, since there always seem to be real programs that violate those conventions, and there are cases where DR is used to run deliberately violating programs (analyzing malware, etc.). Only when such support is intractable do we reluctantly relax that and assume conventions: such as some rseq corner cases. So if it is practical to support it changing we would want to do that. We should add a handler for the prctl call that at least detects a change and provides a warning or error with a TODO to actually handle it.
The places I think of off the top of my head where changing VL definitely matters are:
Scatter/gather expansion. The expanded sequence is an unrolled loop based on the number of elements in the vector. If the vector length changes, so does the number of elements so the expansion won't be valid any more.
Machine context switching. We use ldr/str to save and restore the Z and P registers. Changing the vector length will scale the size of the offsets and transfer size for those instructions.
drmemtrace/raw2trace. We will need to record any vector length changes in the raw trace so it can be handled in raw2trace and any tools which decode instructions
The text was updated successfully, but these errors were encountered:
Adds a new trace marker 'TRACE_MARKER_TYPE_DYNAMIC_VECTOR_LENGTH'
to drcachesim that indicates the current vector length for architectures which have a dynamic vector length that can't be statically determined from the instruction.
The marker is emitted as part of the thread header when running on AArch64 with SVE support, but in the future could also be used to track changes in the vector length after prctl(PR_SVE_SET_VL, ..) system calls (i#6625).
Some SVE load and store instructions such as
LDR <Zt>, [<Xn|SP>{, #<imm>, MUL VL}]
or
ST1D { <Zt>.D }, <Pg>, [<Xn|SP>{, #<imm>, MUL VL}]
scale the immediate offset based on the hardware vector length so knowing the correct vector length for the traced application is important to properly decode and analyse these instructions.
Fixes: #6585
Issues: #6625
In the discussion for #6544 @derekbruening and @abhinav92003 raised the issue of applications which change the vector length at runtime. Currently DynamoRIO assumes that the VL doesn't change at run time, but it is possible that applications can do it anyway using the Linux
prctl()
system call.@derekbruening said:
The places I think of off the top of my head where changing VL definitely matters are:
Scatter/gather expansion. The expanded sequence is an unrolled loop based on the number of elements in the vector. If the vector length changes, so does the number of elements so the expansion won't be valid any more.
Machine context switching. We use ldr/str to save and restore the Z and P registers. Changing the vector length will scale the size of the offsets and transfer size for those instructions.
drmemtrace/raw2trace. We will need to record any vector length changes in the raw trace so it can be handled in raw2trace and any tools which decode instructions
The text was updated successfully, but these errors were encountered: