[Lldb-commits] [Patch for Review] Parsing PTRACE_GETFPREGS in ReadRegister [POSIX x86-64]

[Greg Clayton]

Looks good:

% svn commit
Sending        source/Plugins/Process/POSIX/RegisterContext_x86_64.cpp
Sending        test/functionalities/register/TestRegisters.py
Sending        test/lldbtest.py
Transmitting file data ...
Committed revision 166604.


On Oct 24, 2012, at 8:42 AM, "Thirumurthi, Ashok" <ashok.thirumurthi at intel.com> wrote:

> Attached is a patch to populate RegisterValue when ReadRegister is called for a floating-point register.  As a result “register read –a” now dumps all expected registers.  I tightened TestRegisters.py to keep it so.
>  
> While this effort is patterned after the analogous Darwin plug-ins, there is no optimization at this time to read registers from a cached register set.  So, a ptrace peek is performed for each register even if we’re stopped and the thread and frame haven’t changed.
>  
> Note that the byte-order for vector registers is read from the target process (because the data is read from a ptrace peek on the target process).  I’m not sure why this wasn’t the case with RegisterContextDarwin_x86_64::ReadRegister.
>  
> Another result of this patch is that “expr $xmm0” now takes a different code path.  Essentially, IRInterpreter can’t use the GetScalar returned by RegisterValue.  This isn’t all bad because it went on to crash on POSIX in InterpreterStackFrame while pretending that the vector register was a uint64.  I can work around this failure by adding and supporting Scalar::Type::e_bytes.  However, that introduces a misnomer as my Scalar can be a vector.  I’m all ears for alternatives.
>  
> Cheers,
>  
> -        Ashok
> <fpreg-x86-64.diff>_______________________________________________
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits