<div dir="ltr">Hi Matthew,<div><br></div><div>Thanks for the analysis.</div><div><br></div><div><br><span style="font-family:arial,sans-serif;font-size:13px">> #define DR_OFFSET(reg_index) \</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">> (0xFC + (reg_index * 4))</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">> Can't we just use this in our lldb code?</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">We could, but the fact that it is not lining up right on your side means all the parts between the misaligned bits and the DR registers are also broken. So there's something deeper here going on.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">> </span><span style="font-family:arial,sans-serif;font-size:13px">As the fpregs and fpxregs structs are of differing sizes pushes the offsets of the dr registers out.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">I think you're referring to this part, right?</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"> union</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">+ {</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">+ struct</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">+ {</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">+ uint64_t fip; // Instruction Pointer</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">+ uint64_t fdp; // Data Pointer</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">+ } x86_64;</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">+ struct</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">+ {</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">+ uint32_t fioff; // FPU IP Offset (fip)</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">+ uint32_t fiseg; // FPU IP Selector (fcs)</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">+ uint32_t fooff; // FPU Operand Pointer Offset (foo)</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">+ uint32_t foseg; // FPU Operand Pointer Selector (fos)</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">+ } i386;</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">+ } ptr;</span><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><br></div><div>Both the x86_64 and i386 portion of the structure are unioned, and both are 128 bits wide.</div>
<div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">+ MMSReg stmm[8]; // 8*16 bytes for each FP-reg = 128 bytes</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">+ XMMReg xmm[8]; // 8*16 bytes for each XMM-reg = 128 bytes</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">+ uint32_t padding[56];</span><br></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">These are different than the true x86_64 version to match the x86 32-bit size.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div>The reason I changed them was to solve the original issue of the 32-bit lldb running against a 32-bit inferior trying to read the 64-bit register. Your patch had added some code to say "when reading a 64-bit register value, really just return 32-bits". But the reason it was trying to read 64-bits was because of the way the FPR_SIZE macro was defined. I added a mechanism to allow it to be possibly defined ahead of time, which is what we now do in the case of the i386 register infos setup within the Linux RegisterContext i386 class here:</div>
<div><br></div><span style="font-family:arial,sans-serif;font-size:13px">+#define FPR_SIZE(reg) sizeof(((FPR_i386*)NULL)->reg)</span><br style="font-family:arial,sans-serif;font-size:13px"><div><br></div><div>That, in turn, required that the proper elements be defined in the floating point save region.</div>
<div><br></div><div><br></div><div>Today I'm going to try a few things:</div><div><br></div><div>* build the 32-bit setup with configure/make. This might expose different behavior on my 32-bit systems vs. the cmake/ninja builds I did last week.</div>
<div><br></div><div>* add some logging during 32-bit register setup to dump the offsets of all the relevant parts. I'm going to spit out what I'm getting on my end and would like you to do the same so we can see where we're getting different alignment. This might end up boiling down to compiler flags (which might be exposed when I use configure/make, and might imply we need some #pragma/alignment decls).</div>
<div><br></div><div>It would be great if you can confirm a few things just to make sure all my assumptions are right:</div><div>* What OS are you using? ('uname -a' data)</div><div>* What compiler are you using? (compiler version string)</div>
<div>* What hardware is this running on?</div><div><br></div><div>Thanks Matthew! We'll get this all straightened out.</div><div> <br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 3, 2014 at 6:02 AM, Matthew Gardiner <span dir="ltr"><<a href="mailto:mg11@csr.com" target="_blank">mg11@csr.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, my latest pain in 32-bit linux occurs due to the offset calculations for dr6/7 being broken by the inclusion of the extended floating point registers structure in "struct UserArea". I'm not really sure what we are trying to model here, since, looking at sys/user.h, it's the regular FP registers (user_fpregs_struct) which comprise the user area not the extended ones (user_fpxregs_struct).<br>
<br>
I did try to fix this issue by reinstating the previous definition for FPR_i386, i.e.<br>
<br>
struct FPR_i386<br>
{<br>
int32_t cwd;<br>
int32_t swd;<br>
int32_t twd;<br>
int32_t fip;<br>
int32_t fcs;<br>
int32_t foo;<br>
int32_t fos;<br>
int32_t st_space [20];<br>
};<br>
<br>
Unfortunately, this results in a world of pain, since the numerous "DEFINE_FPR" invocations in RegisterInfos_i386.h rely on the elements contained in user_fpxregs_struct.<br>
<br>
So, I solved this issue in a different (and in my opinion simpler) way - by using the following macro to calculate the offset of a debug register in the user:<br>
<br>
#define DR_OFFSET(reg_index) \<br>
(0xFC + (reg_index * 4))<br>
<br>
Can't we just use this in our lldb code?<br>
<br>
Why do we currently calculate the offsets with copied structures? Do we actually use the structures as structures as well? This is a source of bugs.<br>
<br>
So I'll repeat what I hint to above...<br>
<br>
Can we remove the copied user/register structures and replace the required offsets with integral constant definitions please?<br>
<br>
thanks<span class="HOEnZb"><font color="#888888"><br>
Matthew Gardiner</font></span><div class="im HOEnZb"><br>
<br>
<br>
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom<br>
More information can be found at <a href="http://www.csr.com" target="_blank">www.csr.com</a>. Keep up to date with CSR on our technical blog, <a href="http://www.csr.com/blog" target="_blank">www.csr.com/blog</a>, CSR people blog, <a href="http://www.csr.com/people" target="_blank">www.csr.com/people</a>, YouTube, <a href="http://www.youtube.com/user/CSRplc" target="_blank">www.youtube.com/user/CSRplc</a>, Facebook, <a href="http://www.facebook.com/pages/CSR/191038434253534" target="_blank">www.facebook.com/pages/CSR/<u></u>191038434253534</a>, or follow us on Twitter at <a href="http://www.twitter.com/CSR_plc" target="_blank">www.twitter.com/CSR_plc</a>.<br>
New for 2014, you can now access the wide range of products powered by aptX at <a href="http://www.aptx.com" target="_blank">www.aptx.com</a>.<br></div><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/lldb-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><table cellspacing="0" cellpadding="0" style="color:rgb(136,136,136);font-family:'Times New Roman'"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small">
<td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Todd Fiala |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td>
<td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tfiala@google.com" style="color:rgb(17,85,204)" target="_blank"><span style="background-color:rgb(255,255,204);color:rgb(34,34,34);background-repeat:initial initial">tfiala@google.com</span></a> |</td>
<td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"><font color="#1155cc"> <a>650-943-3180</a></font></td></tr></tbody></table><br></div>
</div>