[PATCH] Fix the remainder of PR22762 (GDB is crashing on DW_OP_piece being used inside of DW_AT_frame_base)

[Adrian Prantl]

> On Mar 10, 2015, at 4:35 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Tue, Mar 10, 2015 at 4:28 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com <mailto:Paul_Robinson at playstation.sony.com>> wrote:
> Yes this is exactly the edge case that we were relying on up to now. There are two problems I have with that:
> 
> 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?
> 
> 
> 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.
> 
> 
> You mean like X86 vector registers?  They're implicitly arrays/structs of values of a smaller size. I don't know that the value of interest always ends up in the "low" part, but maybe it does. I really don't have a handle on X86 vector instructions.
> 
> 
> Can't say I know a great deal about it - but sure, if we can concoct a test case where part of a variable resides in part of a vector register, it'd be worth checking that it behaves appropriately.

I’m not worried so much about the case were the value of interest is in one of the upper parts, because that will not trigger the questionable edge-case; it would translate into a shift-right and mask operation. The real question (for me) is what “defined by the ABI” is ever supposed to mean. I suppose an ABI may specify that a vector of 8-bit values be passed in the subregisters v0-v15 of a 128-bit register w and then we could encode a 2-byte vector that is in v0+v1 as DW_OP_reg[w] DW_OP_piece 1 DW_OP_reg[w] DW_OP_piece 1, but even that I find dubious, because of the amount of implicit state necessary to evaluate this expression. And a single byte in v1 still would need to be expressed via shift+mask.

-- adrian
>  
> 
> --paulr
> 
>   <>
> From: llvm-commits-bounces at cs.uiuc.edu <mailto:llvm-commits-bounces at cs.uiuc.edu> [mailto:llvm-commits-bounces at cs.uiuc.edu <mailto:llvm-commits-bounces at cs.uiuc.edu>] On Behalf Of David Blaikie
> Sent: Tuesday, March 10, 2015 3:36 PM
> To: Adrian Prantl
> Cc: reviews+D8233+public+f5c9e8745840f37b at reviews.llvm.org <mailto:reviews%2BD8233%2Bpublic%2Bf5c9e8745840f37b at reviews.llvm.org>; llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
> Subject: Re: [PATCH] Fix the remainder of PR22762 (GDB is crashing on DW_OP_piece being used inside of DW_AT_frame_base)
> 
>  
> 
>  
> 
>  
> 
> On Tue, Mar 10, 2015 at 3:26 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
> 
>  
> 
> On Mar 10, 2015, at 3:14 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote:
> 
>  
> 
>  
> 
>  
> 
> On Tue, Mar 10, 2015 at 2:50 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
> 
> Hi echristo, dblaikie,
> 
> http://llvm.org/bugs/show_bug.cgi?id=22762 <http://llvm.org/bugs/show_bug.cgi?id=22762>
> 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.
> 
> 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.",
> 
> 
> 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)?
>  
> 
> 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).
> 
>  
> 
> Yes this is exactly the edge case that we were relying on up to now. There are two problems I have with that:
> 
> 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?
> 
> 
> 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.
>  
> 
> 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.
> 
> 
> This bit I don't really understand - perhaps you could provide some expression examples?
>  
> 
> b) is doable, if ugly, but I’d need some help with a).
> 
>  
> 
> -- adrian
> 
>  
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150310/a44ec10d/attachment.html>