On Fri, Jan 22, 2021 at 9:42 AM Jim Ingham <jing...@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 <pa...@labath.sk> wrote: > > > > On 19/01/2021 23:23, David Blaikie wrote: > >> On Tue, Jan 19, 2021 at 1:12 AM Pavel Labath <pa...@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 > >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
