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 <[email protected]> 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 <[email protected]> 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, [email protected] 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 <[email protected]>
> > 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
> >> [email protected]
> >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >
> > _______________________________________________
> > lldb-dev mailing list
> > [email protected]
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
