:-/ The same thing happens if you write Foo &f = *nullptr; It's a reference.
Did you try StringRef::withNullAsEmpty()? BTW what code are you converting? I'm working on some of the options code as we speak. On Wed, Sep 21, 2016 at 1:43 PM Greg Clayton <gclay...@apple.com> wrote: > I am laughing as I convert code over to using StringRef and I get crashes: > > if (name == NULL) > > StringRef is nice enough to implicitly construct a StringRef from NULL or > nullptr so that it can crash for me... > > > On Sep 21, 2016, at 11:09 AM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Adding another thing to my list (thanks to Mehdi and Eric Christopher > for the idea). > > > > Apply libfuzzer to LLDB. Details sparse on what parse of LLDB and how, > but I think it would be easy to come up with candidates. > > > > On Mon, Sep 19, 2016 at 1:18 PM Zachary Turner <ztur...@google.com> > wrote: > > Following up with Kate's post from a few weeks ago, I think the dust has > settled on the code reformat and it went over pretty smoothly for the most > part. So I thought it might be worth throwing out some ideas for where we > go from here. I have a large list of ideas (more ideas than time, sadly) > that I've been collecting over the past few weeks, so I figured I would > throw them out in the open for discussion. > > > > I’ve grouped the areas for improvement into 3 high level categories. > > > > • De-inventing the wheel - We should use more code from LLVM, and > delete code in LLDB where LLVM provides a solution. In cases where there > is an LLVM thing that is *similar* to what we need, we should extend the > LLVM thing to support what we need, and then use it. Following are some > areas I've identified. This list is by no means complete. For each one, > I've given a personal assessment of how likely it is to cause some > (temporary) hiccups, how much it would help us in the long run, and how > difficult it would be to do. Without further ado: > > • Use llvm::Regex instead of lldb::Regex > > • llvm::Regex doesn’t support enhanced mode. > Could we add support for this to llvm::Regex? > > • Risk: 6 > > • Impact: 3 > > • Difficulty / Effort: 3 (5 if we have to add > enhanced mode support) > > • Use llvm streams instead of lldb::StreamString > > • Supports output re-targeting (stderr, stdout, > std::string, etc), printf style formatting, and type-safe streaming > operators. > > • Interoperates nicely with many existing llvm > utility classes > > • Risk: 4 > > • Impact: 5 > > • Difficulty / Effort: 7 > > • Use llvm::Error instead of lldb::Error > > • llvm::Error is an error class that *requires* > you to check whether it succeeded or it will assert. In a way, it's > similar to a C++ exception, except that it doesn't come with the > performance hit associated with exceptions. It's extensible, and can be > easily extended to support the various ways LLDB needs to construct errors > and error messages. > > • Would need to first rename lldb::Error to > LLDBError so that te conversion from LLDBError to llvm::Error could be done > incrementally. > > • Risk: 7 > > • Impact: 7 > > • Difficulty / Effort: 8 > > • StringRef instead of const char *, len everywhere > > • Can do most common string operations in a way > that is guaranteed to be safe. > > • Reduces string manipulation algorithm complexity > by an order of magnitude. > > • Can potentially eliminate tens of thousands of > string copies across the codebase. > > • Simplifies code. > > • Risk: 3 > > • Impact: 8 > > • Difficulty / Effort: 7 > > • ArrayRef instead of const void *, len everywhere > > • Same analysis as StringRef > > • MutableArrayRef instead of void *, len everywhere > > • Same analysis as StringRef > > • Delete ConstString, use a modified StringPool that is > thread-safe. > > • StringPool is a non thread-safe version of > ConstString. > > • Strings are internally refcounted so they can be > cleaned up when they are no longer used. ConstStrings are a large source > of memory in LLDB, so ref-counting and removing stale strings has the > potential to be a huge savings. > > • Risk: 2 > > • Impact: 9 > > • Difficulty / Effort: 6 > > • thread_local instead of lldb::ThreadLocal > > • This fixes a number of bugs on Windows that > cannot be fixed otherwise, as they require compiler support. > > • Some other compilers may not support this yet? > > • Risk: 2 > > • Impact: 3 > > • Difficulty: 3 > > • Use llvm::cl for the command line arguments to the > primary lldb executable. > > • Risk: 2 > > • Impact: 3 > > • Difficulty / Effort: 4 > > • Testing - Our testing infrastructure is unstable, and our test > coverage is lacking. We should take steps to improve this. > > • Port as much as possible to lit > > • Simple tests should be trivial to port to lit > today. If nothing else this serves as a proof of concept while increasing > the speed and stability of the test suite, since lit is a more stable > harness. > > • Separate testing tools > > • One question that remains open is how to > represent the complicated needs of a debugger in lit tests. Part a) above > covers the trivial cases, but what about the difficult cases? In > https://reviews.llvm.org/D24591 a number of ideas were discussed. We > started getting to this idea towards the end, about a separate tool which > has an interface independent of the command line interface and which can be > used to test. lldb-mi was mentioned. While I have serious concerns about > lldb-mi due to its poorly written and tested codebase, I do agree in > principle with the methodology. In fact, this is the entire philosophy > behind lit as used with LLVM, clang, lld, etc. > > > > I don’t take full credit for this idea. I had been toying with a > similar idea for some time, but it was further cemented in an offline > discussion with a co-worker. > > > > There many small, targeted tools in LLVM (e.g. llc, lli, llvm-objdump, > etc) whose purpose are to be chained together to do interesting things. > Instead of a command line api as we think of in LLDB where you type > commands from an interactive prompt, they have a command line api as you > would expect from any tool which is launched from a shell. > > > > I can imagine many potential candidates for lldb tools of this nature. > Off the top of my head: > > • lldb-unwind - A tool for testing the unwinder. Accepts byte > code as input and passes it through to the unwinder, outputting a > compressed summary of the steps taken while unwinding, which could be > pattern matched in lit. The output format is entirely controlled by the > tool, and not by the unwinder itself, so it would be stable in the face of > changes to the underlying unwinder. Could have various options to enable > or disable features of the unwinder in order to force the unwinder into > modes that can be tricky to encounter in the wild. > > • lldb-symbol - A tool for testing symbol resolution. Could have > options for testing things like: > > • Determining if a symbol matches an executable > > • looking up a symbol by name in the debug info, and > mapping it to an address in the process. > > • Displaying candidate symbols when doing name lookup in a > particular scope (e.g. while stopped at a breakpoint). > > • lldb-breakpoint - A tool for testing breakpoints and stepping. > Various options could include: > > • Set breakpoints and out addresses and/or symbol names > where they were resolved to. > > • Trigger commands, so that when a breakpoint is hit the > tool could automatically continue and try to run to another breakpoint, etc. > > • options to inspect certain useful pieces of state about > an inferior, to be matched in lit. > > • lldb-interpreter - tests the jitter etc. I don’t know much > about this, but I don’t see why this couldn’t be tested in a manner similar > to how lli is tested. > > • lldb-platform - tests lldb local and remote platform interfaces. > > • lldb-cli -- lldb interactive command line. > > • lldb-format - lldb data formatters etc. > > • Tests NOW, not later. > > • I know we’ve been over this a million times and it’s not > worth going over the arguments again. And I know it’s hard to write tests, > often requiring the invention of new SB APIs. Hopefully those issues will > be addressed by above a) and b) above and writing tests will be easier. > Vedant Kumar ran some analytics on the various codebases and found that > LLDB has the lowest test / commit ratio of any LLVM project (He didn’t post > numbers for lld, so I’m not sure what it is there). > > • lldb: 287 of the past 1000 commits > > • llvm: 511 of the past 1000 commits > > • clang: 622 of the past 1000 commits > > • compiler-rt: 543 of the past 1000 commits > > This is an alarming statistic, and I would love to see this number > closer to 50%. > > • Code style / development conventions - Aside from just the > column limitations and bracing styles, there are other areas where LLDB > differs from LLVM on code style. We should continue to adopt more of > LLVM's style where it makes sense. I've identified a couple of areas > (incomplete list) which I outline below. > > • Clean up the mess of cyclical dependencies and properly > layer the libraries. This is especially important for things like > lldb-server that need to link in as little as possible, but regardless it > leads to a more robust architecture, faster build and link times, better > testability, and is required if we ever want to do a modules build of LLDB > > • Use CMake instead of Xcode project (CMake supports > Frameworks). CMake supports Apple Frameworks, so the main roadblock to > getting this working is just someone doing it. Segmenting the build > process by platform doesn't make sense for the upstream, especially when > there is a perfectly workable solution. I have no doubt that the resulting > Xcode workspace generated automatically by CMake will not be as "nice" as > one that is maintained by hand. We face this problem with Visual Studio on > Windows as well. The solution that most people have adopted is to continue > using the IDE for code editing and debugging, but for actually running the > build, use CMake with Ninja. A similar workflow should still be possible > with an OSX CMake build, but as I do not work every day on a Mac, all I can > say is that it's possible, I have no idea how impactful it would be on > peoples' workflows. > > • Variable naming conventions > > • I don’t expect anyone is too fond of LLDB’s > naming conventions, but if we’re committed to joining the LLVM ecosystem, > then let’s go all the way. > > • Use more modern C++ and less C > > • Old habits die hard, but this isn’t just a > matter of style. It leads to safer, more robust, and less fragile code as > well. > > • Shorter functions and classes with more narrowly > targeted responsibilities > > • It’s not uncommon to find functions that are > hundreds (and in a few cases even 1,000+) of lines long. We really need to > be better about breaking functions and classes down into smaller > responsibilities. This helps not just for someone coming in to read the > function, but also for testing. Smaller functions are easier to unit test. > > • Convert T foo(X, Y, Error &error) functions to > Expected<T> foo(X, Y) style (Depends on 1.c) > > • llvm::Expected is based on the llvm::Error class > described earlier. It’s used when a function is supposed to return a > value, but it could fail. By packaging the error with the return value, > it’s impossible to have a situation where you use the return value even in > case of an error, and because llvm::Error has mandatory checking, it’s also > impossible to have a sitaution where you don’t check the error. So it’s > very safe. > > > > Whew. That was a lot. If you made it this far, thanks for reading! > > > > Obviously if we were to embark on all of the above, it would take many > months to complete everything. So I'm not proposing anyone stop what > they're doing to work on this. This is just my own personal wishlist > > _______________________________________________ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
