[Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

[David Blaikie via lldb-commits]

On Mon, Jan 25, 2021 at 10:39 AM Jim Ingham <jingham at apple.com> wrote:

> lldb creates a single line table out of the debug_line input and the
> inlined_subroutine info from the debug_info.  For instance, if you have a
> nested set of inlines that all have the same start address, they cannot be
> represented in the debug_line which requires monotonically increasing
> addresses.  But when you are "stepping" into the set of nested inlines,
> lldb would like to represent the step as first stopping before the call in
> the outer function, then stepping one by one into the nested inlines.  I
> don't know why exactly DWARF line tables need to be monotonically
> increasing in address, but we couldn't see any good reason why lldb should
> also have to do this little two-step every time we tried to figure out
> where you are, we decided to merge the info up front.
>
> You could still write Unit Tests accessing the lldb line table
> construction rather than the DWARF debug_line ingestion.  But IIRC the
> layer between the LineEntries in lldb_private and the classes in the SB API
> is pretty thin, so there's less motivation to test that way.
>

This patch/test isn't about inlined subroutines - it's about
DW_TAG_subprograms with DW_AT_ranges - specifically the patch
changes DWARFDebugInfoEntry::BuildFunctionAddressRangeTable - so it sounds
like it probably wouldn't be unit testable via the line table alone (or
perhaps the line table at all). Given the novel (to lldb) functionality,
and partial but untested implementation already in lldb prior to these
recent patches (there was at least one place with a comment explaining why
it was doing something a particular way to support discontiguous functions)
I think the end-to-end testing in some form (SB API or Shell, rather than
the narrower testing of a unit test) is probably valuable to give some more
test coverage to this whole situation, not only the one or two places I've
found specific bugs/fixes.

I'm still mystified why I couldn't reproduce the behavior using the SB API,
but I could using a shell test/using lldb interactively myself. But for now
it seems the Shell test is about the best thing I can do.

- Dave


>
> Jim
>
>
> > On Jan 24, 2021, at 8:32 PM, David Blaikie <dblaikie at gmail.com> wrote:
> >
> >
> >
> > On Fri, Jan 22, 2021 at 9:42 AM Jim Ingham <jingham at apple.com> wrote:
> > If you are just loading an object file and the looking at the line table
> or something like that, would a UnitTest be more suitable?
> >
> > Maybe, though for what it's worth, this isn't an issue with the line
> table (well, not the .debug_line contents) as such - this is testing a
> change to .debug_info - specifically, the use of DW_AT_ranges on a
> DW_TAG_subprogram. But it manifested as breakpoints not having source
> information. I don't know a great deal about how the line table ended up
> interacting with the address ranges specified on the DW_TAG_subprogram, but
> it did in some way.
> >
> > Not sure if that is or isn't especially amenable to unit testing given
> the LLDB architecture of these components.
> >
> > - Dave
> >
> >
> > Jim
> >
> >
> > > On Jan 22, 2021, at 5:37 AM, Pavel Labath <pavel at labath.sk> wrote:
> > >
> > > On 19/01/2021 23:23, David Blaikie wrote:
> > >> On Tue, Jan 19, 2021 at 1:12 AM Pavel Labath <pavel at labath.sk> wrote:
> > >> Yeah - I have mixed feelings about debugger testing here - it is nice
> > >> to have end-to-end tests which makes for handy debugger testing
> > >> (though I guess in theory, debuginfo-tests is the place for
> > >> intentional end-to-end testing), though also being able to test
> > >> different features (DWARF version, split DWARF, dsym V object
> > >> debugging, etc) when they're written as end-to-end tests.
> > >
> > > Yeah, it would be nice if there was a clearer separation between the
> two categories. The current setup has evolved organically, as the
> end-to-end API tests used to be the only kinds of tests.
> > >
> > >
> > >> Can we write non-end-to-end API tests, then?
> > >
> > > Kind of. There is no fundamental reason why one couldn't run llvm-mc
> or whatever as a part of an API test. The main issue is that we don't have
> the infrastructure for that set up right now. I think the reason for that
> is that once you start dealing with "incomplete" executables which cannot
> be run on the host platform, the usefulness of interactivity goes down
> sharply. It is hard for such a test to do something other than load up some
> executable and query its state. This is a perfect use case for a shell test.
> > >
> > > There are exceptions though. For example we have a collection of "API"
> tests which test the gdb-remote communication layer, by mocking one end of
> the connection. Such tests are necessarily interactive, which is why they
> ended up in the API category, but they are definitely not end-to-end tests,
> and they either don't use any executables, or just use a static yaml2objed
> executable. This is why our API tests have the ability to run yaml2obj and
> one could add other llvm tools in a similar fashion.
> > >
> > > Another aspect of end-to-endness is being able to test a specific
> component of lldb, instead of just the debugger as a whole. Here the API
> tests cannot help because the "API" is the lldb public API. However, there
> are also various tricks you can do by using the low-level (debugging)
> commands (like the "image lookup" thing I mentioned) to interact with the
> lower debugger layers in some manner.
> > >
> > >
> > > pl
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20210125/8e73aaef/attachment.html>