Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle changes in SVE vector length on AArch64 #6625

Open
jackgallagher-arm opened this issue Feb 5, 2024 · 0 comments
Open

Handle changes in SVE vector length on AArch64 #6625

jackgallagher-arm opened this issue Feb 5, 2024 · 0 comments

Comments

@jackgallagher-arm
Copy link
Collaborator

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:

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:

  1. 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.

  2. 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.

  3. 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

jackgallagher-arm added a commit that referenced this issue Feb 9, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant