Hello
I have a question regarding offset calculations of registers for x86_64 architecture. In file source/Plugins/Process/Utility/RegisterInfos_x86_64.h:
The macro FPR_OFFSET(reg) calculates the offset of floating point register ‘reg’ with respect to ‘UserArea’ struct while GPR_OFFSET(reg) calculates it wrt to ‘GPR’ struct. Is there any specific reason of calculating the offsets of floating point registers wrt ‘UserArea’ struct and not wrt ‘FPR’ struct (defined in source/Plugins/Process/Utility/RegisterContext_x86.h) ?
All registers are placed into one large buffer that contains everything. All offsets should be the global offset in the register context's data. Typically we should see:
GPR
rax offset 0
rbx offset 8
....
FPR
mm0 offset 128
mm1 offset 160
...
EXC
fpsr offset 256
...
So the offsets should be based on the offset from the start of the one large buffer that contains all register values.
Hi
As per my understanding (please correct if I am wrong):
-
There exists a file for each platform (Architecture+OS) that calculates the offsets for that platform. e.g. RegisterContextLinux_x86_64.cpp for x86_64 architecture on Linux OS.
-
For each platform, offset values for registers might be different because it depends upon the way the members of structures GPR, FPR and UserArea are organized in Platform specific file. e.g. Offset of rax will be 80 and not 0 for RegisterContextLinux_x86_64.cpp because rax lies at 10th position in structure GPR defined in this file.
-
The main motive behind calculating offsets for each register is to fetch data from the correct location in a chunk of data that a ptrace API provides (atleast in case of Linux OS).
Hi
As per my understanding (please correct if I am wrong):
1. There exists a file for each platform (Architecture+OS) that calculates the offsets for that platform. e.g. RegisterContextLinux_x86_64.cpp for x86_64 architecture on Linux OS.
Correct. We allow register context data buffers to just mirror exactly what the OS gives us which is usually N chunks of data representing the raw registers as they would be gotten from the OS supplied functions (like ptrace for reading/writing registers).
2. For each platform, offset values for registers might be different because it depends upon the way the members of structures GPR, FPR and UserArea are organized in Platform specific file. e.g. Offset of rax will be 80 and not 0 for RegisterContextLinux_x86_64.cpp because rax lies at 10th position in structure GPR defined in this file.
Yep, we adapt to the way the OS represents registers in their native buffers. We just require that you append all register sets together into one chunk (GPR + FPR + ...).
3. The main motive behind calculating offsets for each register is to fetch data from the correct location in a chunk of data that a ptrace API provides (atleast in case of Linux OS).
Yes. Just as on MacOSX we mimic how thread_get_state(task_t task, ....) returns registers.
Hi Greg
Thanks for your reply. My next queries are based on the Bug 24457 that I filed 2-3 days ago.
I analyzed and found the reason of this bug for x86_64-Linux platform.
A solution to fix this bug requires change in the definition of macro FPR_OFFSET (defined in RegisterInfos_x86_64.h) to calculate offsets for fpr registers wrt to FPR structure (defined in RegisterContext_x86.h) and not wrt to UserArea structure (defined in RegisterContextLinux_x86_64.cpp).
I am a bit unclear on your statements
“All offsets should be the global offset in the register context’s data” and
“We just require that you append all register sets together into one chunk (GPR + FPR + …)” in your last 2 replies.
In context of this bug, do your statements mean that macro FPR_OFFSET will not be allowed to change?
The offset for each register should be the offset in the register context data buffer, so if the first FPU register currently has 128 as the offset, it shouldn't change to zero if that is the correct offset. If you are seeing issues and believe the offset should be zero, then the bug is somewhere else and needs to be fixed elsewhere. The linux plug-in might be expecting a zero based offset for some registers in some locations, but that should all be fixed within the RegisterContextLinuxx86_64 class.
Greg