Excellent, I'm glad that worked for you!
Jim
On Mar 18, 2014, at 12:47 AM, Andrew MacPherson <andrew.m...@gmail.com> wrote:
> Hi Jim, just saw your checkin from yesterday and gave it a run here and
> stepping is now working exactly as we were hoping for the couple of test
> cases we had on this end. Looks great!
>
>
> On Mon, Mar 17, 2014 at 7:21 PM, Andrew MacPherson <andrew.m...@gmail.com>
> wrote:
> That sounds great, thanks Jim.
>
>
> On Mon, Mar 17, 2014 at 7:01 PM, <jing...@apple.com> wrote:
> I've been working recently on making stepping treat line number 0 as an
> "auto-continuation" of whatever it was doing previously. So for instance if
> you are doing "step over" line 54, and you end up in line 0 I remember that I
> was at line 54, step through the line 0 code, then if I end up back in line
> 54, continue stepping through it. That's why I line line 0 being a real
> line, I know positively that it is artificial compiler goo, not just "dunno"
> code, and can take the appropriate actions. I know there are a few places
> where I haven't done this yet, like if "step out" steps out to code at line
> number 0. But all those instances are bugs and should be fixed in the
> stepping machinery, not by obscuring what the code we've wandered our way
> into is.
>
> BTW, I was handling this in a somewhat ad-hoc way before, the point of
> reworking the ShouldStopHere stuff that I did last week was to make a more
> centralized place to handle this. I'll work the line number 0 stuff over
> there this week, and then see if you are still seeing cases where this code
> leaks out, and if so, file a bug and we'll figure it out.
>
> Jim
>
>
> On Mar 17, 2014, at 9:59 AM, Greg Clayton <gclay...@apple.com> wrote:
>
> > Yes, we should fix our stepping to avoid these line number 0. I would avoid
> > changing LineEntry::IsValid(), but possibly add another check like
> > "IsValidSourceLocation()" that would return
> >
> > bool
> > LineEntry::IsValidSourceLocation() const
> > {
> > return IsValid() && m_line != 0;
> > }
> >
> > We should let Jim comment on any stepping related changed.
> >
> > On Mar 15, 2014, at 1:40 AM, Andrew MacPherson <andrew.m...@gmail.com>
> > wrote:
> >
> >> Ok, that makes sense, I should have provided more context.
> >>
> >> We use LLVM's DIBuilder to add debug info to our JITed KL language and
> >> there are certain functions we provide which are internal and for which we
> >> don't want to provide line info. We want these functions to show up named
> >> in stack traces but would prefer to not have file and line info show up.
> >> We have been passing 0 as the line number for these functions (DIBuilder's
> >> createFunction() requires a line number) which makes them behave as we
> >> want in gdb, however in LLDB they show up coming from our dummy internal
> >> file name on line 0.
> >>
> >> This isn't a big deal but would be nice to fix, the one which prompted us
> >> to look into this though was around stepping. In gdb these internal
> >> functions are skipped by default because they have no source and line
> >> info, whereas when stepping in LLDB (with the avoids-no-debug flags set)
> >> stepping still hits these functions even though there's no source
> >> available for them, which we'd like to avoid.
> >>
> >> Taking another look maybe the correct fix would be to modify
> >> LineEntry::IsValid() to add a check for line != 0 too?
> >>
> >> Thanks,
> >> Andrew
> >>
> >>
> >> On Fri, Mar 14, 2014 at 7:29 PM, Greg Clayton <gclay...@apple.com> wrote:
> >> I agree with Jim in that it is nice to know when a compiler told us line
> >> 0, versus "invalid info" where UINT32_MAX is the value. I would vote to
> >> leave things as is unless you have a convincing argument otherwise.
> >>
> >>
> >> On Mar 14, 2014, at 11:21 AM, jing...@apple.com wrote:
> >>
> >>> lldb uses LLDB_INVALID_LINE_NUMBER to mean line number information is not
> >>> available, and 0 to mean this is code that was generated by the compiler,
> >>> but is artificial. That's the way clang marks code (e.g. junk generated
> >>> by ARC) that lldb will need to step through, or whatever, but should not
> >>> show to the user.
> >>>
> >>> That's a useful distinction, and I'd like to maintain it. What bad
> >>> behavior are you seeing based on this?
> >>>
> >>> Jim
> >>>
> >>> On Mar 14, 2014, at 1:49 AM, Andrew MacPherson <andrew.m...@gmail.com>
> >>> wrote:
> >>>
> >>>> gdb assumes that any debug entry with a line number of 0 means that line
> >>>> number information is not available (see struct symtab_and_line here):
> >>>>
> >>>> http://www.opensource.apple.com/source/gdb/gdb-967/src/gdb/symtab.h
> >>>>
> >>>> lldb currently uses UINT32_MAX for the same thing.
> >>>>
> >>>> I suggest changing lldb to use the same value as gdb so that it's
> >>>> possible to mark line entry data as invalid in the same way for both
> >>>> debuggers.
> >>>>
> >>>> Thanks,
> >>>> Andrew
> >>>> <invalid-line-number.patch>_______________________________________________
> >>>> lldb-dev mailing list
> >>>> lldb-dev@cs.uiuc.edu
> >>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >>>
> >>> _______________________________________________
> >>> lldb-dev mailing list
> >>> lldb-dev@cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >>
> >>
> >
>
>
>
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
