How %fs and %gs segment register works in X86_64 DR mechanism

[TOMYUE]

Sorry to bother, when I read and debug the DynamoRIO codebase, I find myself confusing about the `%fs` and `%gs` segment register usage, and lost in the codebase. 

My confusion is as follows:
   I found both of `%fs` and `%gs` were used in `instr_create_save/restore_to/from_tls` routines, and marco `SEG_TLS`, which is equal to marco `SEG_GS` is used in some tls_based_offset instr create functions. But I found in `/core/arch/arch_exports.h` spill slot is designed to be stored in `fs:offset`. Then why some save to TLS routines use `gs` register? And when I debug the context switch process between the DynamoRIO and the code cache native execution, it uses %gs register, I guess its where to store the `mcontext` data, but due to my limited background and relatively weak understanding of the codebase, I'm not sure what `gs` register is doing before `save_simd_reg` instrs in context switch.

The objective of my study on this is:
   I want to change the core of DynamoRIO to help me save more simd registers , and in some cases the avx512 mask registers. I want to save them into TLS so I come to study the codebase. 

Thanks so much! Please forgive me if there is anything inappropriate or unclear about my question.

   

[Derek Bruening]

For helping clients preserve SIMD registers used in their inserted instrumentation it is much better to augment the drreg library (https://dynamorio.org/page_drreg.html) and not modify core DR.

Adding SIMD support to drreg is https://github.com/DynamoRIO/dynamorio/issues/3844 and there is a draft PR at https://github.com/DynamoRIO/dynamorio/pull/3893.

If you would like to revive that PR that would be the best next step.

--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dynamorio-users/00a54c86-a963-4f19-9d1b-e6f021fff255n%40googlegroups.com.

[TOMYUE]

Very appreciated! Thank you so much for your guidance on using drreg within clients to achieve the goal of preserving SIMD registers. I‘ll try to explore if I can improve the existing implementation of drreg, and try to contribute. 

I'm a graduate student currently researching binary translation. DynamoRIO is an impressive industrial-strength project, and it has been incredibly beneficial for us students to study and learn from. Currently, I am exploring binary-level auto-vectorization and attempting to add such capabilities to the DynamoRIO core.

I am currently considering whether it's feasible to utilize the `gs:offset` or `fs:offset` space for temporarily storing some SIMD register values. However, I am not entirely clear about the purpose of instructions like`movabs %rax, %gs:0x10` and  `jmpq *%gs:0x10` as below figures shown, which are used during the switching between DR context and native code cache execution. I'm thinking about hardcode instruction to spill SIMD register value into `%gs:offset` but I'm not sure whether it will crash the DR internal mechanism or not.

If you could provide some insights about why use %gs in this way or offer advice on how I might achieve my goals within the DynamoRIO core, I would be deeply grateful.
Thank again for your time and support❤️！

[Derek Bruening]

I would again suggest that new features like this for use in clients only (i.e., core DR does not need this for its own operation) be implemented in extension libraries and not by changing core DR so I would suggest not focusing on core DR's operation.  The philosophy is to keep core DR as simple as possible to reduce complexity and thus stability and other issues and to modularize with extra features located in libraries.  Please examine the PR I pointed to which has a proposed design for where to store SIMD values.  IIRC it uses indirection as there likely is not enough directly addressable TLS (at least on some platforms) for storing a whole bunch of SIMD values.  That's also what Dr. Memory had to do for shadow values for SIMD: an indirection step in order to fit them.

To view this discussion visit https://groups.google.com/d/msgid/dynamorio-users/35de3084-1b05-4a68-9a14-841ba3222d56n%40googlegroups.com.

[TOMYUE]

Very appreciated! I'll carefully examine the PR you pointed and try to do something on that.