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
