[PATCH] [RFC] Rewrite the way we generate debug locations for variables.

[Robinson, Paul]

> -----Original Message-----
> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-
> bounces at cs.uiuc.edu] On Behalf Of Adrian Prantl
> Sent: Thursday, January 30, 2014 12:41 PM
> To: reviews+D2658+public+165c5c32e55e8f4a at llvm-reviews.chandlerc.com
> Cc: llvm-commits at cs.uiuc.edu
> Subject: Re: [PATCH] [RFC] Rewrite the way we generate debug locations
> for variables.
> 
> 
> On Jan 30, 2014, at 12:07, Alexey Samsonov <samsonov at google.com> wrote:
> >
> >    BB1:
> >      DBG_VALUE: var "x" is in %rax
> >      jmp BB3
> >    BB2:
> >      DBG_VALUE: var "x" is in %rbx
> >      jmp BB3
> >    BB3:
> >      // what DBG_VALUE for "x" should we insert here?
> 
> This is a great example, showing why we really want to extend the ranges
> instead. The interesting bit here is that we would want to have two
> overlapping location ranges:
>   BB1, BB3 var "x" is in $rax
>   BB2, BB3 var "x" is in $rbx

No, no, no.  At BB3, the location of "x" is UNKNOWN.
When stopped at BB3, we cannot guarantee that the debugger knows
which block it came from.  Therefore the location of "x" is
ambiguous, and therefore we cannot say where it is at all.
--paulr

> and incidentally the DWARF spec says that: "Address ranges defined by
> normal location list entries may overlap."
> I wonder if debuggers can deal with this, though.
> 
> thanks,
> Adrian
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits