On 2016-12-22 19:02, David Blaikie wrote:> if you could simplify it down a bit, that might be helpful - not sure > there's a lot to be gained - I imagine it is just a quirk of how we > handle these things in the backend to make normal debug info work, but > there might be some things to be done to help. >That's my guess too, special behavior when it sees an alloca. Here's a simplified version, works on i386 windows and linux (most likely 64bits too but i don't have that handy to test) in gdb a break Test1; break Test2; run; step; locals (fine for Test1); run; step; (broken for Test2) https://gist.github.com/carlokok/202961f81bbcf1a28139eae1d6fbf1ca -- Carlo Kok RemObjects Software
I think probably the simplest answer is that dbg.declare documents that it
must point to an alloca ("This intrinsic provides information about a local
element (e.g., variable). The first argument is metadata holding the alloca
for the variable. ") - so it's probably best not to think too hard
about
what it does when that criteria is not met.
http://llvm.org/docs/SourceLevelDebugging.html#llvm-dbg-declare
Adrian: Another thing to check for in the debug info verifier?
Carlo: You may want/need to use a llvm.dbg.value instead.
- Dave
On Thu, Dec 22, 2016 at 10:33 AM Carlo Kok <ck at remobjects.com> wrote:
>
>
> On 2016-12-22 19:02, David Blaikie wrote:
> > if you could simplify it down a bit, that might be helpful - not sure
> > there's a lot to be gained - I imagine it is just a quirk of how
we
> > handle these things in the backend to make normal debug info work, but
> > there might be some things to be done to help.
> >
>
> That's my guess too, special behavior when it sees an alloca.
> Here's a simplified version, works on i386 windows and linux (most
> likely 64bits too but i don't have that handy to test)
>
> in gdb a break Test1; break Test2; run; step; locals (fine for Test1);
> run; step; (broken for Test2)
> https://gist.github.com/carlokok/202961f81bbcf1a28139eae1d6fbf1ca
>
> --
> Carlo Kok
> RemObjects Software
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161222/66485b57/attachment.html>
> On Dec 22, 2016, at 1:05 PM, David Blaikie <dblaikie at gmail.com> wrote: > > I think probably the simplest answer is that dbg.declare documents that it must point to an alloca ("This intrinsic provides information about a local element (e.g., variable). The first argument is metadata holding the alloca for the variable. ") - so it's probably best not to think too hard about what it does when that criteria is not met. http://llvm.org/docs/SourceLevelDebugging.html#llvm-dbg-declare > > Adrian: Another thing to check for in the debug info verifier?[Sorry, I missed this thread.] So far I avoided adding this as a check because I expected us to retire dbg.declare in the "near future" :-p The current state of things is that llvm.dbg.declare pointing to an alloca is the only *supported* use of it. That said, I have seen declares pointing to other values in the wild (i.e. generated by clang) before, and apparently there are some combinations that do work, but they do so by accident and not by design.> Carlo: You may want/need to use a llvm.dbg.value instead.The two options you have are: - describe the alloca with a dbg.declare (will be valid for the entire scope of the variable) This is how clang describes variables at -O0. - describe each SSA value the variable assumes with a dbg.value The Swift and Julia frontends do this even for unoptimized code. -- adrian> > - Dave > > On Thu, Dec 22, 2016 at 10:33 AM Carlo Kok <ck at remobjects.com> wrote: > > > On 2016-12-22 19:02, David Blaikie wrote: > > if you could simplify it down a bit, that might be helpful - not sure > > there's a lot to be gained - I imagine it is just a quirk of how we > > handle these things in the backend to make normal debug info work, but > > there might be some things to be done to help. > > > > That's my guess too, special behavior when it sees an alloca. > Here's a simplified version, works on i386 windows and linux (most > likely 64bits too but i don't have that handy to test) > > in gdb a break Test1; break Test2; run; step; locals (fine for Test1); > run; step; (broken for Test2) > https://gist.github.com/carlokok/202961f81bbcf1a28139eae1d6fbf1ca > > -- > Carlo Kok > RemObjects Software