https://github.com/jimingham updated
https://github.com/llvm/llvm-project/pull/89324
>From b6021cf31e4c607dc4d541b4dd3b028e93050767 Mon Sep 17 00:00:00 2001
From: Jim Ingham
Date: Thu, 18 Apr 2024 15:02:37 -0700
Subject: [PATCH 1/3] Check for null oso SymbolFile in
https://github.com/JDevlieghere approved this pull request.
LGTM with Alex' suggestion and the code formatted.
https://github.com/llvm/llvm-project/pull/89324
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://github.com/jimingham updated
https://github.com/llvm/llvm-project/pull/89324
>From b6021cf31e4c607dc4d541b4dd3b028e93050767 Mon Sep 17 00:00:00 2001
From: Jim Ingham
Date: Thu, 18 Apr 2024 15:02:37 -0700
Subject: [PATCH 1/2] Check for null oso SymbolFile in
@@ -848,9 +848,18 @@ SymbolFileDWARFDebugMap::ResolveSymbolContext(const
Address _so_addr,
debug_map_entry->data.GetOSOFileAddress();
Address oso_so_addr;
if (oso_module->ResolveFileAddress(oso_file_addr, oso_so_addr)) {
-
https://github.com/bulbazord edited
https://github.com/llvm/llvm-project/pull/89324
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/bulbazord approved this pull request.
https://github.com/llvm/llvm-project/pull/89324
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 6f1e23b47d428d792866993ed26f4173d479d43d
b6021cf31e4c607dc4d541b4dd3b028e93050767 --
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: None (jimingham)
Changes
The couple other places that use the oso module's SymbolFile, they check that
it's non-null, so this is just an oversight in ResolveSymbolContext.
I didn't add a test for this (but did add a log message for the
https://github.com/jimingham created
https://github.com/llvm/llvm-project/pull/89324
The couple other places that use the oso module's SymbolFile, they check that
it's non-null, so this is just an oversight in ResolveSymbolContext.
I didn't add a test for this (but did add a log message for
