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

[David Blaikie via lldb-commits]

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/20210124/76364a97/attachment.html>