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
