[lldb-dev] Offset Calculations for Registers on Linux x86_64

Abhishek Aggarwal via lldb-dev lldb-dev at lists.llvm.org
Mon Aug 17 08:06:01 PDT 2015


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 <gclayton at apple.com> wrote:

>
> > On Aug 14, 2015, at 12:25 AM, Abhishek Aggarwal <abhiinnitald at 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 <gclayton at 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 at 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 at lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150817/bcdf54fd/attachment.html>


More information about the lldb-dev mailing list