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? - Abhishek Aggarwal On Fri, Aug 14, 2015 at 6:17 PM, Greg Clayton <gclay...@apple.com> wrote: > > > On Aug 14, 2015, at 12:25 AM, Abhishek Aggarwal <abhiinnit...@gmail.com> > wrote: > > > > 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. > > > > > On Thu, Aug 13, 2015 at 6:42 PM, Greg Clayton <gclay...@apple.com> > wrote: > > 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. > > > > > On Aug 13, 2015, at 2:26 AM, Abhishek Aggarwal via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > > > > > > 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) ? > > > > > > _______________________________________________ > > > lldb-dev mailing list > > > lldb-dev@lists.llvm.org > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > > > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
