| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
These benchmarks don't get run as part of the regular API test-suite.
And I'm not aware of any CI running this. Also, I haven't quite managed
to actually run them locally using the `bench.py` script. It looks like
these are obsolete, so I'm proposing to remove the infrastructure around
it entirely.
If anyone does know of a use for these do let me know.
|
|
get_threads_stopped_at_breakpoint_id (#108281)
If multiple breakpoints are hit at the same time, multiple stop reasons
are reported, one per breakpoint.
Currently, `get_threads_stopped_at_breakpoint_id` only checks the first
such reason.
|
|
platform (#108183)
I've been testing against qemu-aarch64 using the qemu-user platform,
which doesn't support get-file:
```
AssertionError: False is not true : Command 'platform get-file "/proc/cpuinfo" <...>/TestAArch64LinuxMTEMemoryRegion.test_mte_regions/cpuinfo
Command output:
get-file failed: unimplemented
' did not return successfully
```
QEMU itself does support overriding cpuinfo for the emulated process
(https://gitlab.com/qemu-project/qemu/-/commit/a55b9e72267085957cadb0af0a8811cfbd7c61a9)
however we'd need to be able to read the cpuinfo before the process
starts, so I'm not attempting to use this feature.
Instead if the get-file fails, assume empty cpuinfo so we can at least
carry on testing. I've logged the failure and the reason to the trace so
developers can find it.
```
runCmd: platform get-file "/proc/cpuinfo" <...>/TestAArch64LinuxMTEMemoryRegion.test_mte_regions/cpuinfo
check of return status not required
runCmd failed!
Failed to get /proc/cpuinfo from remote: "get-file failed: unimplemented"
All cpuinfo feature checks will fail.
```
For now this only helps AArch64 but I suspect that RISC-V, being even
more mix and match when it comes to extensions, may need this in future.
And I know we have some folks testing against qemu-riscv at the moment.
|
|
This fix is based on a problem with cxx_compiler and cxx_linker macros
on Windows.
There was an issue with compiler detection in paths containing "icc". In
such case, Makefile.rules thought it was provided with icc compiler.
To solve that, utilities detection has been rewritten in Python.
The last element of compiler's path is separated, taking into account
the platform path delimiter, and compiler type is extracted, with regard
of possible cross-toolchain prefix.
---------
Co-authored-by: Pavel Labath <pavel@labath.sk>
|
|
(#105905)
Refactoring `stackTrace` to perform frame look ups in a more on-demand
fashion to improve overall performance.
Additionally adding additional information to the `exceptionInfo`
request to report exception stacks there instead of merging the
exception stack into the stack trace. The `exceptionInfo` request is
only called if a stop event occurs with `reason='exception'`, which
should mitigate the performance of `SBThread::GetCurrentException`
calls.
Adding unit tests for exception handling and stack trace supporting.
|
|
There is no need to support Python 2.7 anymore, Python 3.3+ has
`subprocess.DEVNULL`. This is good practice and also prevents file
handles from
staying open unnecessarily.
Also remove a couple unused or unneeded `__future__` imports.
|
|
Added support for "supportsInstructionBreakpoints" capability and now it
this command is triggered when we set instruction breakpoint.
We need this support as part of enabling disassembly view debugging.
Following features should work as part of this feature enablement:
1. Settings breakpoints in disassembly view: Unsetting the breakpoint is
not happening from the disassembly view. Currently we need to unset
breakpoint manually from the breakpoint List. Multiple breakpoints are
getting set for the same $
2. Step over, step into, continue in the disassembly view
The format for DisassembleRequest and DisassembleResponse at
https://raw.githubusercontent.com/microsoft/vscode/master/src/vs/workbench/contrib/debug/common/debugProtocol.d.ts
.
Ref Images:
Set instruction breakpoint in disassembly view:
After issuing continue:
---------
Co-authored-by: Santhosh Kumar Ellendula <sellendu@hu-sellendu-hyd.qualcomm.com>
Co-authored-by: Santhosh Kumar Ellendula <sellendu@hu-sellendu-lv.qualcomm.com>
|
|
lines. (#105456)
Previously, when output like `"hello\nworld\n"` was produced by lldb (or
the process) the message would be sent as a single Output event. By
being a single event this causes VS Code to treat this as a single
message in the console when handling displaying and filtering in the
Debug Console.
Instead, with these changes we send each line as its own event. This
results in VS Code representing each line of output from lldb-dap as an
individual output message.
Resolves #105444
|
|
VS Code requests the `instruction` stepping granularity if the assembly
view is currently focused. By implementing `StepGranularity`, we can
hence properly single-step through assembly code.
|
|
We only need to see that 1 frame of the stack is in user code. No need
to carry on looking.
Doing so actually caused a test failure on Armv8 Ubuntu Jammy where
a libc function does not have a display name. I'm sure I'm going to
get stung by this elsewhere, but for this test, breaking early
sidesteps the problem.
|
|
with stripped binaries (#99362)
@walter-erquinigo found the the [PR with testing and a fix for
DebugInfoD](https://github.com/llvm/llvm-project/pull/98344) caused an
issue when working with stripped binaries.
The issue is that when you're working with split-dwarf, there are *3*
possible files: The stripped binary the user is debugging, the
"only-keep-debug" *or* unstripped binary, plus the `.dwp` file. The
debuginfod plugin should provide the unstripped/OKD binary. However, if
the debuginfod plugin fails, the default symbol locator plugin will just
return the stripped binary, which doesn't help. So, to address that, the
SymbolVendorELF code checks to see if the SymbolLocator's
ExecutableObjectFile request returned the same file, and bails if that's
the case. You can see the specific diff as the second commit in the PR.
I'm investigating adding a test: I can't quite get a simple repro, and
I'm unwilling to make any additional changes to Makefile.rules to this
diff, for Pavlovian reasons.
|
|
These changes aim to support cross-compilation build on Windows host for
Linux target for API tests execution. They're not final: changes will
follow for refactoring and adjustments to make all tests pass.
Chocolatey make is recommended to be used since it is maintained better
than GnuWin32 mentioned here
https://lldb.llvm.org/resources/build.html#windows (latest GnuWin32
release is dated by 2010) and helps to avoid problems with building
tests (for example, GnuWin32 make doesn't support long paths and there
are some other failures with building for Linux with it).
Co-authored-by: Pavel Labath <pavel@labath.sk>
|
|
(#101169)
This test has been flaky lately
(https://github.com/llvm/llvm-project/issues/101162) and I disabled it
everywhere initially.
I found that it always uses "x86_64" for the program architecture so the
test was "passing" elsewhere but I don't think it was meant to. So I
have added a define to pass on the host's architecture when compiling.
This makes it work on AArch64 as well.
While I'm here I've fixed the uint64_t formatting warnings by using the
defined formats that'll work everywhere.
In addition, I found that the function names include "()" on Linux, so
now we check for "foo" or "foo()".
The test cpp file has never been, or was only partially formatted so
I've not formatted the changes, just kept to the local style.
I've removed the Linux skip to see if any of this helps the timeouts,
and to verify the build command changes. If the timeouts come back I'll
disable it again.
|
|
This causes a number of tests be `UNRESOLVED` on Windows if
`getCompiler()` has a space in the name, because `getCompilerBinary()`
unconditionally splits on whitespace and returns the first result, which
might just be`"C:\Program"` if using a compiler such as `clang-cl` `cl`
from the absolute path to Visual studio's installation directory.
Co-authored-by: kendal <kendal@thebrowser.company>
|
|
(#99934)
## Issue
Attempting to run the lldb API tests against a remote-android target
fails with the error `NameError: name 'urlparse' is not defined`.
## Root Cause
It looks the Python import of `urlparse` was removed by mistake in
22ea97d7bfd65abf68a68b13bf96ad69be23df54. This import is only used when
running the lldb API tests against a remote-android target so it went
unnoticed.
## Fix
This change simply puts back the missing import. It is a one line
change.
fixes #99931
## Validation
Tested on Fedora 39 with an attached Android device:
`cd llvm-project`
`cmake -S llvm -B build -G Ninja -DLLVM_ENABLE_PROJECTS='clang;lldb'
-DCMAKE_BUILD_TYPE=Release -DLLDB_ENABLE_PYTHON=On`
`ninja -C build`
`./build/bin/lldb-dotest --arch aarch64 --out-of-tree-debugserver
--platform-name=remote-android
--platform-working-dir=/data/local/tmp/ds2
--platform-url=connect://localhost:5432 --compiler
~/Android/Sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/linux-x86_64/bin/clang`
|
|
In MinGW make, the `%windir%` variable has a lowercase name `$(windir)`
when launched from cmd.exe, and `$(WINDIR)` name when launched from
MSYS2, since MSYS2 represents standard Windows environment variables
names in upper case.
This commit makes Makefile.rules consider both run variants.
|
|
Remove commands for OS/HOST_OS detection from Makefile.rules to simplify
it, since logic for these variables has been implemented in
`lldb/packages/Python/lldbsuite/test/lldbplatformutil.py`
(7021e44b2f0e11717c0d82456bad0fed4a0b48f9).
|
|
Add information about RISCV first register in python API testsuite, that
is used to check register readability in tests.
Fixed tests on RISCV target:
TestBreakpointByFileColonLine.BreakpointByLineAndColumnTestCase
TestAddressBreakpoints.AddressBreakpointTestCase
TestBreakpointAutoContinue.BreakpointAutoContinue
TestInterruptBacktrace.TestInterruptingBacktrace
TestBadAddressBreakpoints.BadAddressBreakpointTestCase
TestScriptedResolver.TestScriptedResolver
TestStopHookScripted.TestStopHooks
TestBreakpointConditions.BreakpointConditionsTestCase
TestLocalVariables.LocalVariablesTestCase
TestFindLineEntry.FindLineEntry
TestScriptedResolver.TestScriptedResolver
TestInlineSourceFiles.InlineSourceFilesTestCase
TestModuleAndSection.ModuleAndSectionAPIsTestCase
TestFrameVar.TestFrameVar
TestInferiorAssert.AssertingInferiorTestCase
TestInferiorCrashing.CrashingInferiorTestCase
TestInferiorCrashingStep.CrashingInferiorStepTestCase
TestRegistersIterator.RegistersIteratorTestCase
TestCoroutineHandle.TestCoroutineHandle
TestWithLimitDebugInfo.TestWithLimitDebugInfo
TestLLDBIterator.LLDBIteratorTestCase
TestMemoryWrite.MemoryWriteTestCase
TestNestedTemplate.NestedTemplateTestCase
TestParrayVrsCharArrayChild.TestParrayVrsCharArrayChild
TestRecursiveInferior.CrashingRecursiveInferiorTestCase
TestRecursiveInferiorStep.CrashingRecursiveInferiorStepTestCase
TestRunLocker.TestRunLocker
TestSampleTest.RenameThisSampleTestTestCase
TestUniqueTypes3.UniqueTypesTestCase3
TestPrintStackTraces.ThreadsStackTracesTestCase
TestUnicodeSymbols.TestUnicodeSymbols
TestUnusedInlinedParameters.TestUnusedInlinedParameters
TestValueVarUpdate.ValueVarUpdateTestCase
TestPtrRef2Typedef.PtrRef2TypedefTestCase
TestDataFormatterStdIterator.StdIteratorDataFormatterTestCase
TestDataFormatterStdString.StdStringDataFormatterTestCase
TestDataFormatterStdVBool.StdVBoolDataFormatterTestCase
|
|
This is motivated by the upcoming refactor of libc++'s
`__compressed_pair` in https://github.com/llvm/llvm-project/pull/76756
As this will require changes to numerous LLDB libc++ data-formatters
(see early draft https://github.com/llvm/llvm-project/pull/96538), it
would be nice to have a test-suite that will actually exercise both the
old and new layout. We have a matrix bot that tests old versions of
Clang (but currently those only date back to Clang-15). Having them in
the test-suite will give us quicker signal on what broke.
We have an existing test that exercises various layouts of `std::string`
over time in `TestDataFormatterLibcxxStringSimulator.py`, but that's the
only STL type we have it for. This patch proposes a new
`libcxx-simulators` directory which will take the same approach for all
the STL types that we can feasibly support in this way (as @labath
points out, for some types this might just not be possible due to their
implementation complexity). Nonetheless, it'd be great to have a record
of how the layout of libc++ types changed over time.
Some related discussion:
*
https://github.com/llvm/llvm-project/pull/97568#issuecomment-2213426804
|
|
This reverts commit 2fa1220a37a3f55b76a29803d8333b3a3937d53a.
This reverts commit b9496a74eb4029629ca2e440c5441614e766f773.
The patch #98344 causes a crash in LLDB when parsing some files like `numpy.libs/libgfortran-daac5196.so.5.0.0` on graviton (you can download it in https://drive.google.com/file/d/12ygLjJwWpzdYsrzBPp1JGiFHxcgM0-XY/view?usp=drive_link if you want to troubleshoot yourself).
The assert that is hit is the following:
```
llvm-project/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2452: std::pair<unsigned int, std::map<long unsigned int, lldb_private::AddressClass> > ObjectFileELF::ParseSymbolTable(lldb_private::Symtab*, lldb::user_id_t, lldb_private::Section*): Assertion `strtab->GetObjectFile() == this' failed.
[383588:383636:20240716,025305.572639:ERROR crashpad_client_linux.cc:780] Crashpad isn't enabled
```
This object file doesn't have apparently a strings table but LLDB still tries to process it due to the code that is being reverted.
|
|
This is all the tests and fixes I've had percolating since my first
attempt at this in January. After 6 months of trying, I've given up on
adding the ability to test DWP files in LLDB API tests. I've left both
the tests (disabled) and the changes to Makefile.rules in place, in the
hopes that someone who can configure the build bots will be able to
enable the tests once a non-borked dwp tool is widely available.
Other than disabling the DWP tests, this continues to be the same diff
that I've tried to land and
[not](https://github.com/llvm/llvm-project/pull/90622)
[revert](https://github.com/llvm/llvm-project/pull/87676)
[five](https://github.com/llvm/llvm-project/pull/86812)
[times](https://github.com/llvm/llvm-project/pull/85693)
[before](https://github.com/llvm/llvm-project/pull/96802). There are a
couple of fixes that the testing exposed, and I've abandoned the DWP
tests because I want to get those fixes finally upstreamed, as without
them DebugInfoD is less useful.
|
|
Makefile.rules uses HOST_OS and OS variables for determining host and target
OSes for API tests compilation.
This commit moves the platform detection logic from Makefile to Python lldb
test suite.
This is useful for the case of Windows-to-Linux cross-testing.
|
|
Reverts llvm/llvm-project#96802
Attempt #5 fails. It's been 6 months. I despise Makefile.rules and have
no ability to even *detect* these failures without _landing_ a diff. In
the mean time, we have no testing for DWP files at all (and a regression
that was introduced, that I fix with this diff) so I'm going to just
remove some of the tests and try to land it again, but with less testing
I guess.
|
|
This is the same diff I've put up at many times before. I've been trying
to add some brand new functionality to the LLDB test infrastucture
(create split-dwarf files!), and we all know that no good deed goes
unpunished. The last attempt was reverted because it didn't work on the
Fuchsia build.
There are no code differences between this and
[the](https://github.com/llvm/llvm-project/pull/90622)
[previous](https://github.com/llvm/llvm-project/pull/87676)
[four](https://github.com/llvm/llvm-project/pull/86812)
[diffs](https://github.com/llvm/llvm-project/pull/85693) landed &
reverted (due to testing infra failures). The only change in this one is
the way `dwp` is being identified in `Makefile.rules`.
Thanks to @petrhosek for helping me figure out how the fuchsia builders
are configured. I now prefer to use llvm-dwp and fall back to gnu's dwp
if the former isn't found. Hopefully this will work everywhere it needs
to.
|
|
(#97328)
This test only runs on Windows and fails because we're passing a literal
of the wrong type to random.randrange.
Co-authored-by: kendal <kendal@thebrowser.company>
|
|
This fixes TestGdbRemoteConnection.py failing after PR #91570 on
AArch64 Windows LLDB buildbot.
https://lab.llvm.org/buildbot/#/builders/141/builds/376
|
|
Adding a "port" property to the VsCode "attach" command likely extends
the functionality of the debugger configuration to allow attaching to a
process using PID or PORT number.
Currently, the "Attach" configuration lets the user specify a pid. We
tell the user to use the attachCommands property to run "gdb-remote ".
Followed the below conditions for "attach" command with "port" and "pid"
We should add a "port" property. If port is specified and pid is not,
use that port to attach. If both port and pid are specified, return an
error saying that the user can't specify both pid and port.
Ex - launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "lldb-dap Debug",
"type": "lldb-dap",
"request": "attach",
"gdb-remote-port":1234,
"program": "${workspaceFolder}/a.out",
"args": [],
"stopOnEntry": false,
"cwd": "${workspaceFolder}",
"env": [],
}
]
}
---------
Co-authored-by: Santhosh Kumar Ellendula <sellendu@hu-sellendu-hyd.qualcomm.com>
Co-authored-by: Santhosh Kumar Ellendula <sellendu@hu-sellendu-lv.qualcomm.com>
|
|
from PEP8
(https://peps.python.org/pep-0008/#programming-recommendations):
> Comparisons to singletons like None should always be done with is or
is not, never the equality operators.
Co-authored-by: Eisuke Kawashima <e-kwsm@users.noreply.github.com>
|
|
from PEP8
(https://peps.python.org/pep-0008/#programming-recommendations):
> Comparisons to singletons like None should always be done with is or
is not, never the equality operators.
Co-authored-by: Eisuke Kawashima <e-kwsm@users.noreply.github.com>
|
|
Use the packaging [1] module for parsing version numbers, instead of
pkg_resources which is distributed with setuptools. I recently switched
over to using the latter, knowing it was deprecated (in favor of the
packaging module) because it comes with Python out of the box. Newer
versions of setuptools have removed `pkg_resources` so we have to use
packaging.
[1] https://pypi.org/project/packaging/
|
|
Test Plan:
llvm-lit
llvm-project/lldb/test/API/tools/lldb-dap/console/TestDAP_console.py
|
|
This argument allows to specify the path to make which is used by
LLDB API tests to compile test programs.
It might come in handy for setting up cross-platform remote runs of API tests on Windows host.
It can be used to override the make path of LLDB API tests using `LLDB_TEST_USER_ARGS` argument:
```
cmake ...
-DLLDB_TEST_USER_ARGS="...;--make;C:\\Path\\to\\make.exe;..."
...
```
|
|
This argument allows to set specific sysroot pass which will be used for
building LLDB API test programs.
It might come in handy for setting up cross-platform remote runs of API
tests on Windows host.
It can be useful for cross-compiling LLDB API tests. The argument can be
set using `LLDB_TEST_USER_ARGS` argument:
```
cmake ...
-DLLDB_TEST_USER_ARGS="...;--sysroot;C:\path\to\sysroot;..."
...
```
|
|
The don't currently work (and they're also not particularly useful,
since all of the remote stuff happens inside lldb).
This saves us from annotating tests one by one.
|
|
Reverts llvm/llvm-project#92572 due to Fuchsia CI breakages (using CLI
tools in tests that weren't necessarily built).
|
|
Here we go with attempt number five. Again, no changes to the LLDB code
diff, which has been reviewed several times.
For the tests, I added a `@skipIfCurlSupportMissing` annotation so that
the Debuginfod mocked server stuff won't run, and I also disabled
non-Linux/FreeBSD hosts altogether, as they fail for platform reasons on
macOS and Windows. In addition, I updated the process for extracting the
GNU BuildID to no create a target, per some feedback on the previous
diff.
For reference, previous PR's (landed, backed out after the fact for
various reasons) #90622, #87676, #86812, #85693
---------
Co-authored-by: Kevin Frei <freik@meta.com>
|
|
runCmd() is called from Base.getCPUInfo() but implemented only in
TestBase(Base). Usually it works if TestBase is used. But call
getCPUInfo() from a class based on Base will cause something like
```
File "E:\projects\llvm-nino\lldb\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1256, in getCPUInfo
self.runCmd('platform get-file "/proc/cpuinfo" ' + cpuinfo_path)
AttributeError: 'TestGdbRemoteExpeditedRegisters' object has no attribute 'runCmd'
```
BTW, TestBase.setUp() called runCmd() before applying
LLDB_MAX_LAUNCH_COUNT and LLDB_TIME_WAIT_NEXT_LAUNCH.
This patch fixes the test TestGdbRemoteExpeditedRegisters in case of
Windows host and Linux target.
|
|
A lot of `TestConcurrent*.py` expect one of the threads to crash, but we
weren't checking for it properly.
Possibly because signal reporting got better on FreeBSD at some point,
and it now shows the same info as Linux does.
```
lldb-api :: functionalities/inferior-changed/TestInferiorChanged.py
lldb-api :: functionalities/inferior-crashing/TestInferiorCrashing.py
lldb-api :: functionalities/inferior-crashing/TestInferiorCrashingStep.py
lldb-api :: functionalities/inferior-crashing/recursive-inferior/TestRecursiveInferior.py
lldb-api :: functionalities/inferior-crashing/recursive-inferior/TestRecursiveInferiorStep.py
lldb-api :: functionalities/thread/concurrent_events/TestConcurrentCrashWithBreak.py
lldb-api :: functionalities/thread/concurrent_events/TestConcurrentCrashWithSignal.py
lldb-api :: functionalities/thread/concurrent_events/TestConcurrentCrashWithWatchpoint.py
lldb-api :: functionalities/thread/concurrent_events/TestConcurrentCrashWithWatchpointBreakpointSignal.py
```
Fixes #48777
`TestConcurrentTwoBreakpointsOneSignal.py` no longer fails, at least on
an AWS instance, so I've removed the xfail there.
|
|
It can be used in tests #91918, #91931 and such.
|
|
Reproduced with Python 3.12.3
|
|
While adding a UI feature in VSCode to toggle hex/dec in variables view
window. I noticed that it does not work after second toggle. Then I
noticed that there is a bug that we only explicitly set hex format not
reset back to default during further toggle. The new test demonstrates
the bug.
This PR resets the format back to default if not using hex. One
complexity is that, we explicitly set registers value format to
AddressInfo, which shouldn't be overridden by default or hex settings.
---------
Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
|
|
And "LLDB Debuginfod tests and a fix or two (#90622)".
f8fedfb6802173372ec923f99f31d4af810fbcb0 /
2d4acb086541577ac6ab3a140b9ceb9659ce7094
As it has caused a test failure on 32 bit Arm:
https://lab.llvm.org/buildbot/#/builders/17/builds/52580
Expr/TestStringLiteralExpr.test. The follow up did fix
lang/c/shared_lib_stripped_symbols/TestSharedLibStrippedSymbols.py
but not the other failure.
|
|
`ifeq` needs to be at the beginning of a line, otherwise it's
interpreted as part of the recipe.
|
|
I'm taking yet another swing at getting these tests going, on the
hypothesis that the problems with buildbots & whatnot are because
they're not configured with CURL support, which I've confirmed would
cause the previous tests to fail. (I have no access to an ARM64 linux
system, but I did repro the failure on MacOS configured without CURL
support)
So, the only difference between this diff and
[previous](https://github.com/llvm/llvm-project/pull/85693)
[diffs](https://github.com/llvm/llvm-project/pull/87676) that have
already been approved is that I've added a condition to the tests to
only run if Debuginfod capabilities should be built into the binary. I
had done this for these tests when they were [Shell
tests](https://github.com/llvm/llvm-project/pull/79181) and not API
tests, but I couldn't find a direct analog in any API test, so I used
the "plugins" model used by the intel-pt tests as well.
---------
Co-authored-by: Kevin Frei <freik@meta.com>
|
|
|
|
|
|
(#90607)
|
|
using the macOS version as a proxy. I can't reproduce any of these
failures locally, but the tests all use pexpect and probably have bad
timeout behavior under high load.
|
|
that separates out language and version. To avoid reinventing the wheel
and introducing subtle incompatibilities, this API uses the table of
languages and versiond defined by the upcoming DWARF 6 standard
(https://dwarfstd.org/languages-v6.html). While the DWARF 6 spec is not
finialized, the list of languages is broadly considered stable.
The primary motivation for this is to allow the Swift language plugin to
switch between language dialects between, e.g., Swift 5.9 and 6.0 with
out introducing a ton of new language codes. On the main branch this
change is considered NFC.
Depends on https://github.com/llvm/llvm-project/pull/89980
|
|
This patch provides the initial implementation for the "Step Into
Specific/Step In Targets" feature in VSCode DAP.
The implementation disassembles all the call instructions in step range
and try to resolve operand name (assuming one operand) using debug info.
Later, the call target function name is chosen by end user and specified
in the StepInto() API call.
It is v1 because of using the existing step in target function name API.
This implementation has several limitations:
* Won't for indirect/virtual function call -- in most cases, our
disassembler won't be able to solve the indirect call target
address/name.
* Won't work for target function without debug info -- if the target
function has symbol but not debug info, the existing
ThreadPlanStepInRange won't stop.
* Relying on function names can be fragile -- if there is some middle
glue/thunk code, our disassembler can only resolve the glue/thunk code's
name not the real target function name. It can be fragile to depend
compiler/linker emits the same names for both.
* Does not support step into raw address call sites -- it is a valid
scenario that in Visual Studio debugger, user can explicitly choose a
raw address to step into which land in the function without debug
info/symbol, then choose UI to load the debug info on-demand for that
module/frame to continue exploring.
A more reliable design could be extending the ThreadPlanStepInRange to
support step in based on call-site instruction offset/PC which I will
propose in next iteration.
---------
Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
|
