Git Product home page Git Product logo

lldb-eval's Introduction

lldb-eval - blazing fast debug expression evaluation

Build Status

What

lldb-eval is an LLDB-based library for evaluating debug expressions in the context of the debugged process. All modern debuggers support evaluating expressions to inspect the target process state: print out variables, access member fields, etc. lldb-eval is basically a REPL-like library, that allows to inspect the process state using the familiar C++ syntax. The primary use-case is IDE integration (for example, Stadia for Visual Studio).

Why

LLDB has a very powerful built-in expression evaluator (available via expr command). It can handle almost any valid C++ as well as perform function calls. But the downside of this power is poor performance, especially for large programs with lots of debug information. This is not as critical for interactive use, but doesn't work well for implementing IDE integrations. For example, Stadia debugger for Visual Studio evaluates dozens and hundreds of expressions for every "step", so it has to be fast.

lldb-eval makes a trade-off between performance and completeness, focusing on performance. It features a custom expression parser and relies purely on the debug information, aiming at sub-millisecond evaluation speed.

Build & Test

Dependencies

Linux

Install the dependencies:

sudo apt install lld-11 clang-11 lldb-11 llvm-11-dev libclang-11-dev liblldb-11-dev libc++-11-dev libc++abi-11-dev

Or build them from source, see the instructions in the LLDB documentation.

cmake \
    -GNinja \
    -DCMAKE_INSTALL_PREFIX="~/src/llvm-project/build_optdebug/install" \
    -DCMAKE_BUILD_TYPE=RelWithDebInfo \
    -DLLVM_ENABLE_PROJECTS="lldb;clang;lld" \
    -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libunwind" \
    -DLLVM_TARGETS_TO_BUILD="X86" \
    ../llvm

Windows

On Windows we need to build LLDB (and other parts) from source. The steps are basically the same as for Linux. You will need: CMake, Ninja and Visual Studio (tested with Visual Studio 2019 16.6.5).

Hint: You can install the dependencies via Chocolatey.

Run the x64 Native Tools Command Prompt for VS 2019:

git clone https://github.com/llvm/llvm-project.git
cd llvm-project
mkdir build_x64_optdebug
cd build_x64_optdebug

cmake ^
    -DCMAKE_INSTALL_PREFIX='C:\src\llvm-project\build_optdebug\install' ^
    -DCMAKE_BUILD_TYPE=RelWithDebInfo ^
    -DLLVM_ENABLE_PROJECTS='lldb;clang;lld' ^
    -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libunwind" \
    -DLLVM_TARGETS_TO_BUILD="X86" \
    -DLLDB_ENABLE_PYTHON=0 ^
    -GNinja ^
    ../llvm

ninja install

Build

lldb-eval uses Bazel, you can find the installation instructions on its website.

You need to set the LLVM_INSTALL_PATH environmental variable with a location to your LLVM installation:

# (Linux) If you installed the packages via "apt install".
export LLVM_INSTALL_PATH=/usr/lib/llvm-10

# If you built from source using the instruction above.
export LLVM_INSTALL_PATH=~/src/llvm-project/build_optdebug/install
# (Windows) If you built from source using the instructions above.
$env:LLVM_INSTALL_PATH = C:\src\llvm-project\build_optdebug\install

Now you can build and test lldb-eval:

# Build and run all tests
bazel test ...:all

# Evaluate a sample expression
bazel run tools:exec -- "(1 + 2) * 42 / 4"

Depending on your distribution of LLVM, you may also need to provide --@llvm_project//:llvm_build={static,dynamic} flag. For example, if your liblldb.so is linked dynamically (this is the case when installing via apt), then you need to use llvm_build=dynamic. The build script tries to choose the correct default value automatically, but it can be wrong in some situations (please, report and contribute ๐Ÿ™‚).

Hint: You can add this option to your user.bazelrc !

Local per-repo Bazel config

You can create user.bazelrc in the repository root and put there your local configuration. Check Bazel docs for the format. For example:

# Building on Linux (usually don't need this, Bazel detects automatically)
build --config=linux
# Using statically linked liblldb.so
build --@llvm_project//:llvm_build=static

Publications

Disclaimer

This is not an officially supported Google product.

lldb-eval's People

Contributors

daryashirokova avatar henryrlee avatar jaro-sevcik avatar octurion avatar patriosthegreat avatar pfaffe avatar shyamliagrawal avatar tonkosi avatar werat avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

lldb-eval's Issues

Support looking up functions as function pointers

Assuming the program:

int main(int argc, char* argv[]) {
  return 0;
}

EvaluateExpression("main") should return an object holding a function pointer to main.

This can be implemented via SBTarget::FindFunctions(), which returns a list of SBSymbolContext items. Symbol context hold information about the function type and its address, so we can create an SBValue representing the function pointer.

dumb question: how exactly do you use this?

sorry if this is a dumb question but how exactly do i use lldb-eval in tandem with lldb? I've got it built (which wasn't completely straightforward) but e.g.

(pytorch_dev) [mlevental@devgpu019:lldb-eval (master)]$ LLVM_INSTALL_PATH=/data/users/mlevental/llvm-project/llvm bazel run tools:exec -- "(1 + 2) * 42 / 4"
INFO: Analyzed target //tools:exec (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //tools:exec up-to-date:
  bazel-bin/tools/exec
INFO: Elapsed time: 0.133s, Critical Path: 0.00s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action
INFO: Running command line: bazel-bin/tools/exec '(1' + '2)' bazel-bin bazel-lldb-eval bazel-out bazel-testlogs BUILD build_defs CONTRIBUTING.md docs LICENSE lldb-eval README.md testdata tools WORKSPACEINFO: Build completed successfully, 1 total action
Can't find the breakpoint location.
(pytorch_dev) [mlevental@devgpu019:lldb-eval (master)]$ 

so it necessitates being run within the context of lldb even for this.

does one need to rebuild lldb,lldb-server linking against liblldb-eval.so or something like that?

updating OSS-Fuzz releases

I was trying to fix the OSS-Fuzz build of lldb-eval recently (google/oss-fuzz#9305) and ran into some failing issues for UBSAN and coverage builds, e.g.:

In file included from external/llvm_project/include/clang/Basic/DiagnosticIDs.h:71:
/usr/local/include/clang/Basic/DiagnosticCommonKinds.inc:11:1: error: redefinition of enumerator 'DIAG'
DIAG(err_cannot_open_file, CLASS_ERROR, (unsigned)diag::Severity::Fatal, "cannot open file '%0': %1", 0, SFINAE_SubstitutionFailure, false, true, true, false, 0)                                                 
^                                                                                                                                           
/usr/local/include/clang/Basic/DiagnosticCommonKinds.inc:6:1: note: previous definition is here                                             
DIAG(err_arcmt_nsinvocation_ownership, CLASS_ERROR, (unsigned)diag::Severity::Error, "NSInvocation's %0 is not safe to be used with an object with ownership other than __unsafe_unretained", 0, SFINAE_SubstitutionFailure, false, true, true, false, 0)                               
^                                                                     
/usr/local/include/clang/Basic/DiagnosticCommonKinds.inc:11:5: error: missing ',' between enumerators                                       
DIAG(err_cannot_open_file, CLASS_ERROR, (unsigned)diag::Severity::Fatal, "cannot open file '%0': %1", 0, SFINAE_SubstitutionFailure, false, true, true, false, 0)                                                                                                                       
    ^
/usr/local/include/clang/Basic/DiagnosticCommonKinds.inc:13:185: error: too many arguments provided to function-like macro invocation
DIAG(err_cxx2b_size_t_suffix, CLASS_ERROR, (unsigned)diag::Severity::Error, "'size_t' suffix for literals is a C++2b feature", 0, SFINAE_SubstitutionFailure, false, true, true, false, 0)

I assume it was because of these lines need updating: https://github.com/google/oss-fuzz/blob/0ac9b0f8ed9e28ba84bf4f3a332c783ed093d154/projects/lldb-eval/build.sh#L24-L43

Do you know if this is because the archives needs updating? The current clang in OSS-Fuzz infrastructure is 15.0.0

Anonymous structs/unions don't work

Accessing members of anonymous structs/unions doesn't work:

struct S {
  struct {
    int f;
  };
} s;
s.f = 1;
> bazel run tools/exec -- "s.f"
...
<expr>:1:3: no member named 'f' in 'S'
s.f
  ^

When looking up members we should descent into anonymous members:

Every member of an anonymous struct is considered to be a member of the enclosing struct or union. This applies recursively if the enclosing struct or union is also anonymous.

Upgrading lldb-eval OSS-Fuzz to Ubuntu 20.04

Hi,

Recently OSS-Fuzz upgrade it's base builder images to Ubuntu 20.04 from the old 16.04 Xenial image. There has been a migration of projects all switching to Ubuntu 20.04 and lldb-eval is one of two remaining project to upgrade. I was looking to do this myself, but then I noticed in the OSS-Fuzz build you rely on LLVM releases published on the lldb-eval repository which is probably easiest for you to update. OSS-Fuzz now uses clang-14 (up from clang-12).

Please see this issue on the OSS-Fuzz side of things: google/oss-fuzz#6302

The specific lines that need change in lldb-eval are the following:

https://github.com/google/oss-fuzz/blob/1c5c258a49303068b81d7813d53a88aa31b626e7/projects/lldb-eval/Dockerfile#L17-L21

If you change those lines in the build will break and will need upgrading, and that's essentially what I ask in this issue. It would be great if we could get it updated!

Implement debugger intrinsic `__findnonnull`

__findnonnull is an important intrinsic used by NatVis in the CustomListItems element -- https://docs.microsoft.com/en-us/visualstudio/debugger/create-custom-views-of-native-objects?view=vs-2019#customlistitems-expansion

I couldn't find any documentation for it, but empirically it looks like this:

template <typename T>
int __findnonnull(T** ptr, int64_t size) {
  if (size < 0 || size > 100000000) {
    error("Passing in a buffer size that is negative or in excess of 100 million to __findnonnull() is not allowed.");
  }
  for (int i = 0; i < size; ++ i) {
    if (ptr[i] != nullptr) {
      return i;
    }
  }
  return -1;
}

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.