<div dir="ltr">I am a bit late to the party, but anyways, here are my thoughts on the issues here:<br><br>On 19 September 2016 at 21:18, Zachary Turner via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br>> Difficulty / Effort: 3 (5 if we have to add enhanced mode support)<br>><br>> Use llvm streams instead of lldb::StreamString<br>><br>> Supports output re-targeting (stderr, stdout, std::string, etc), printf<br>> style formatting, and type-safe streaming operators.<br>><br>> Interoperates nicely with many existing llvm utility classes<br>><br>> Risk: 4<br>><br>> Impact: 5<br>><br>> Difficulty / Effort: 7<br>><br>I would also mention the logging infrastructure here. I've been thinking about how to make that more streamlined, and I plan to come with a proposal, but I am a bit busy at the moment.<br><br><br>> Port as much as possible to lit<br>><br>> Simple tests should be trivial to port to lit today.  If nothing else this<br>> serves as a proof of concept while increasing the speed and stability of the<br>> test suite, since lit is a more stable harness.<br>I am afraid that we are still pretty far from a solution that will fit all use-cases, mostly thinking about the remote-tests here. Part of the reason for that is that nobody except me and Tamas knows exactly how it works (?). Please make sure we're included in the design discussions to make sure the new solution does not lack some basic features we need.<br><br>> lldb-unwind - A tool for testing the unwinder.  Accepts byte code as input<br>> and passes it through to the unwinder, outputting a compressed summary of<br>> the steps taken while unwinding, which could be pattern matched in lit.  The<br>> output format is entirely controlled by the tool, and not by the unwinder<br>> itself, so it would be stable in the face of changes to the underlying<br>> unwinder.  Could have various options to enable or disable features of the<br>> unwinder in order to force the unwinder into modes that can be tricky to<br>> encounter in the wild.<br>+100<br>Right now the only way to test the instruction emulation is to make a program containing some instructions and run it. This means:<br>- you need to have the hardware capable of running that code<br>- the tests have high overhead<br>- it can be hard to tickle the compiler into producing the corner cases you might want to test (and there's no guarantee that the next version of the compiler will still produce the corner-case you had in mind)<br><br>In theory all you need to test the emulation is to feed it the instruction stream and check the validate the generated unwind plan.<br><br><br><br>> Clean up the mess of cyclical dependencies and properly layer the libraries.<br>> This is especially important for things like lldb-server that need to link<br>> in as little as possible, but regardless it leads to a more robust<br>> architecture, faster build and link times, better testability, and is<br>> required if we ever want to do a modules build of LLDB<br>+1<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>               • Use llvm::cl for the command line arguments to the primary lldb executable.<br>>                       • Risk: 2<br>>                       • Impact: 3<br>>                       • Difficulty / Effort: 4<br>Easy and fine to switch over to. We might need to port some getopt_long functionality into it if it doesn't handle all of the things that getopt_long does. For example arguments and options can be interspersed in getopt_long(). You can also terminate your arguments with "--". It accepts single dashes for long option names if they don't conflict with short options. Many things like this.</blockquote><div><br></div><div>At one point I made a CL which does that  <<a href="http://reviews.llvm.org/D17724">http://reviews.llvm.org/D17724</a>>. With the reformat it might be tricky to resurrect, but I think I can still pull it off. One of the problems there is that will be pretty hard to make that consistent with the interpreter command line as that one uses getopt (and we can't make the interpreter use llvm::cl, as that one relies on global variables). Two solutions I see here are:</div><div>- teach llvm::cl to not use global vars - I think that could be pretty worthwhile, as it has a very nice interface and it would enable it to be used in more contexts. It still won't exactly match the current getopt() interface (but I think it comes sufficiently close already, and we don't have to care about the difference).</div><div>- use llvm::opt - it can handle all crazy gcc arguments, so I'm pretty sure it can be made to work for our use case. However (and precisely because of that), it is extremely unwieldy. I looked at it for a couple of hours and I still could not figure out how it's supposed to be used. (but, I guess we could find someone on the llvm side, who could help us with that).</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">Part of the problem is just that I think we don't have the tools we need to write effective tests.  We have a lot of tests that only work on a particular platform, or with a particular language runtime, or all these different variables that affect the configurations under which the test should pass.  In an ideal world we would be able to test the lion's share of the debugger on any platform.  The only thing that's platform specific is really the loader.  But maybe we have a huge block of code that itself is not platform specific, but only gets run as a child of some platform specific branch.  Now coverage of that platform-inedpenent branch is limited or non-existant, because it depends on being able to have juuust the right setup to tickle the debugger into running it.</span></blockquote><div><br></div><div>Don't forget we have other architectures as well (arm, mips, SystemZ?). But, in general, I agree with the sentiment. One should not need a specific architecture, specific os, and a specific compiler just to be able to run a test (which is why our buildbot runs the test suite six times (and the tests themselves are triplicated along the debug info axis automatically) to get reasonable coverage).</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><span class="gmail-im" style="font-size:12.8px">> However, diffs between the two trees are now at least not cluttered<br></span><span class="gmail-im" style="font-size:12.8px">> with whitespace and formatting differences. I'll try to take another<br></span><span class="gmail-im" style="font-size:12.8px">> look at these.</span><span class="gmail-im" style="font-size:12.8px"><br></span><span style="font-size:12.8px">I am actually in the process of fixing all of this as we speak, so don't do any work on the DWARF parser. It will all be fixed in the next month or so!</span></blockquote><div><br></div><div>Please don't make this a huge code-drop of a months worth of changes. That's one of the things that is expressly against llvm developer policy <<a href="http://llvm.org/docs/DeveloperPolicy.html#incremental-development">http://llvm.org/docs/DeveloperPolicy.html#incremental-development</a>>.</div><div> </div></div>