<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 11, 2015 at 1:08 PM, Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
> On Mar 11, 2015, at 12:41 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Wed, Mar 11, 2015 at 11:26 AM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br>
><br>
>> On Mar 11, 2015, at 11:22 AM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br>
>><br>
>><br>
>>> On Mar 11, 2015, at 11:16 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
>>><br>
>>><br>
>>><br>
>>> On Tue, Mar 10, 2015 at 3:53 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br>
>>><br>
>>>> On Mar 10, 2015, at 3:35 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Tue, Mar 10, 2015 at 3:26 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br>
>>>><br>
>>>>> On Mar 10, 2015, at 3:14 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> On Tue, Mar 10, 2015 at 2:50 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br>
>>>>> Hi echristo, dblaikie,<br>
>>>>><br>
>>>>> <a href="http://llvm.org/bugs/show_bug.cgi?id=22762" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=22762</a><br>
>>>>> The symptom was that DW_AT_frame_base should never use a DW_OP_(bit)_piece, the bug was that AddMachineRegPiece incorrectly created pieces to describe values that occupy only a subregister. Change this to emit a bit mask instead.<br>
>>>>><br>
>>>>> I'm posting this for review because emitting the bit mask increases the size occupied for DWARF expressions for sub-registers (~5 bytes for a 32-bit subregister). Previously we would (incorrectly!) use DW_OP_piece to describe a value occupying part of a register. However, "DW_OP_piece provides a way of describing how large a part of a variable a particular DWARF location description refers to.",<br>
>>>>><br>
>>>>> The spec also says "If the piece is located in a register, but does not occupy the entire register, the placement of the piece within that register is defined by the ABI. " - so we can use this in some cases at least. Should we? I assume it just means if we say _piece of size 1 in a register of size 4 we get the low byte (whatever definition of 'low' there is)?<br>
>>>>><br>
>>>>> not the size and offset of an entire variable inside a super-register. The way that most debuggers implement DW_OP_piece this sort of works out for subregisters that are at offset 0, but it causes confusion if the expression needs to be composed (such as in DW_AT_frame_base, or if the subregister contains only a part of the variable).<br>
>>>><br>
>>>> Yes this is exactly the edge case that we were relying on up to now. There are two problems I have with that:<br>
>>>> a) how do we implement the “defined by the ABI” predicate correctly? Assume that it’s always the subregister at offset 0 and wait until someone complains?<br>
>>>><br>
>>>> I'd probably be OK with this, open to other opinions, but it seems pretty simply like "we stuffed this number in a big register, but we don't need all the bits in the big register, so take the lowest bits that we specify" - any platform that did anything stranger than that... well, we should probably have a talk with/about them anyway, so I wouldn't mind if them running into this feature was what caused us to have that discussion<br>
>>><br>
>>> Fine. I’ll do it this way then.<br>
>>><br>
>>>> .<br>
>>>><br>
>>>> b) it doesn’t compose well, so we’d need to explicitly forbid it inside of DW_AT_frame_base and inside of a larger piece expression.<br>
>>>><br>
>>>> This bit I don't really understand - perhaps you could provide some expression examples?<br>
>>><br>
>>> As for DW_AT_frame_base, according to the PR, gdb just crashes if it encounters a DW_OP_piece in there. More generally, since the expression inside DW_AT_frame_base is just going to be evaluated when a DW_OP_fbreg is encountered, it makes the result of an expression like "DW_OP_fbreg 4 DW_OP_piece 4 DW_OP_fbreg 8 DW_OP_piece 4” highly ambiguous.<br>
>>><br>
>>> I'm still really not following how piece, frame_base, and fbreg are all connected to this issue.<br>
>>><br>
>>> When/where do we use a piece to describe the frame_base?<br>
>><br>
>> On x86_64-pc-linux-gnux32 the frame base is ebp, but in 64-bit mode ebp doesn’t have DWARF register number, so we need a way saying “the lower 32 bits or rbp”. Before this patch we would emit "DW_OP_reg(rbp) DW_OP_piece 4", after this patch it is "DW_OP_reg(rbp) DW_OP_constu 0xffffff DW_OP_and".<br>
>><br>
>>> Is GDB's (which version?) implementation of fbreg not respecting the size of the piece specified in a _piece in frame_base?<br>
>><br>
>> According to the PR (I didn’t verify that) gdb crashes when it encounter a DW_OP_piece in DW_AT_frame_base.<br>
>> -> <a href="http://llvm.org/bugs/show_bug.cgi?id=22762" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=22762</a><br>
> This might just be the sort of thing we should punt to GDB - but, admittedly, might need to workaround it in the interim :/ (would be good to document as such, if that's the case)<br>
<br>
</div></div>Agreed, details below.<br>
<span class=""><br>
><br>
> ( Even if gdb wouldn’t be crashing we cannot use a DW_OP_piece in DW_AT_frame_base because of the ambiguity outlined in <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150309/265207.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150309/265207.html</a>. )<br>
><br>
> I don't really understand the ambiguity you're referring to - could you provide more details?<br>
<br>
</span>Let’s assume<br>
DW_AT_frame_base( DW_OP_reg5 DW_OP_piece 4 ) // lower 32 bits of rbp<br>
<br>
My argument was based on the assumption that a debugger might expand<br>
  DW_OP_fbreg N<br>
to<br>
  [frame_base] DW_OP_consts N DW_OP_add DW_OP_deref<br>
<br>
which would cause a problem in a location that describes multiple pieces:<br>
  DW_AT_location( DW_OP_fbreg 0 DW_OP_piece 4 DW_OP_fbreg 4 DW_OP_piece 4 )<br>
<br>
However, after reading the definition of DW_AT_frame_base again, it seems as if the expectation is more that the expression in DW_AT_frame_base has to be fully evaluated separately first before the result is pushed onto the stack (and at least LLDB appears to implement it this way, too): "On more sophisticated systems [DW_AT_frame_base] might be a location list that adjusts the offset according to changes in the stack pointer as the PC changes.”<br>
So I’m feeling less confident about this argument now.<br></blockquote><div><br>Yeah, I don't /think/ that's a reasonable implementation.<br><br>So, yeah, I have about ~65% confidence that this should just work and it's a bug in GDB, so I'd encourage you to file a GDB bug, commit the workaround as you have it (few comments incoming) with some note in the commit message and/or a description in a comment about what we think we're working around here.<br><br>- David<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-- adrian<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
><br>
>><br>
>> -- adrian<br>
>><br>
>>><br>
>>><br>
>>> For the larger expression, I suppose it actually works with the “defined by the ABI”-strategy. Consider a 2-byte struct on x86_64 where the lower byte is in al and the higher byte is in bl: DW_OP_reg0 DW_OP_piece 1 DW_OP_reg4 DW_OP_piece 1.<br>
>>> And the same struct in al:bh needs some shifting either way.<br>
>>><br>
>>><br>
>>>><br>
>>>> b) is doable, if ugly, but I’d need some help with a).<br>
>>><br>
>>> Ugly (but compact) it is, then! :-)<br>
>>><br>
>>> thanks!<br>
>>> adrian<br>
>>><br>
>>><br>
>><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div></div>