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

[Alexey Samsonov]

On Fri, Jan 31, 2014 at 3:16 AM, Robinson, Paul <
Paul_Robinson at playstation.sony.com> wrote:

> > -----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
>

I agree. Overlapping address ranges mean that the variable is stored in
several
places at the same time, but here we have ambiguity, not redundancy.
Probably, the example should be clarified, though:
BB1:
  put "x" in %rax
  DBG_VALUE: var "x" is in %rax
  clobber %rbx
  jmp BB3
BB2:
  put "x" in %rbx
  DBG_VALUE: var "x" is in %rbx
  clobber %rax
  jmp BB3
BB3:
  // where is "x"?



>
> > 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
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>



-- 
Alexey Samsonov, MSK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140131/b32e6d85/attachment.html>