google / lldb-eval Goto Github PK

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.

OSS-Fuzz has found a bug in this project. Please see https://oss-fuzz.com/testcase?key=4735374460583936 for details and reproducers.

This issue is mirrored from https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48043 and will auto-close if the status changes there.

If you have trouble accessing this report, please file an issue at https://github.com/google/oss-fuzz/issues/new.

Some functionality of lldb-eval depends on the patches we contributed to LLDB -- https://github.com/google/lldb-eval/blob/master/docs/lldb-patches.md

Some of the patches are not yet submitted or not available in earlier versions of LLVM. For running pre-commit tests in GitHub Actions it would be nice to have these patches, so we can tests everything.

struct Base1 {
  int x;
  int y;
};

struct Base2 : Base1 {
};

struct Base3 {
  int z;
};

struct Foo : Base2, Base3 {
};

Foo foo;

Evaluating foo.z produces wrong result, likely because there's a bug somewhere in ParserContext::GetMemberInfo().

OSS-Fuzz has found a bug in this project. Please see https://oss-fuzz.com/testcase?key=5240820006256640 for details and reproducers.

This issue is mirrored from https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=61834 and will auto-close if the status changes there.

If you have trouble accessing this report, please file an issue at https://github.com/google/oss-fuzz/issues/new.

__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;
}

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.

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?

OSS-Fuzz has found a bug in this project. Please see https://oss-fuzz.com/testcase?key=6277346723495936 for details and reproducers.

This issue is mirrored from https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=60538 and will auto-close if the status changes there.

If you have trouble accessing this report, please file an issue at https://github.com/google/oss-fuzz/issues/new.

OSS-Fuzz has found a bug in this project. Please see https://oss-fuzz.com/testcase?key=6424124517384192 for details and reproducers.

This issue is mirrored from https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=49728 and will auto-close if the status changes there.

If you have trouble accessing this report, please file an issue at https://github.com/google/oss-fuzz/issues/new.

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!

LLDB's EvaluateExpression() supports macros (if they're present in the debug info) -- llvm/llvm-project@a0fb69d

We should see what it would take to support them in lldb-eval as well.

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