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

Pavel Labath via lldb-commits lldb-commits at lists.llvm.org
Fri Jan 22 05:37:18 PST 2021


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


More information about the lldb-commits mailing list