llvm-project.git/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py, branch main Unnamed repository; edit this file 'description' to name the repository. More refinement of call site handling in stepping. (#114628) 2024-11-05T18:33:24+00:00 jimingham jingham@apple.com 2024-11-05T18:33:24+00:00 23a01a413d29f2d5b1f6204d0237e3884ae0231e When you set a "next branch breakpoint" and run to it while stepping, you have to claim the stop at that breakpoint to be the top of the inlined call stack, or you will seem to "step in" and then plans might try to step back out again. This records the PrefferedLineEntry for next branch breakpoints and adds a test to make sure this works. 
When you set a "next branch breakpoint" and run to it while stepping,
you have to claim the stop at that breakpoint to be the top of the
inlined call stack, or you will seem to "step in" and then plans might
try to step back out again.

This records the PrefferedLineEntry for next branch breakpoints and adds
a test to make sure this works.
 [lldb][test] Fix formatting in TestInlineStepping.py 2024-10-31T09:08:00+00:00 David Spickett david.spickett@linaro.org 2024-10-31T09:08:00+00:00 7557972884106e6bdaf00eabe1a8cafec861a7fe Fixes a218f0f354e9df2ce689686be503f3d85fea44f9 
Fixes a218f0f354e9df2ce689686be503f3d85fea44f9
[lldb][test] Skip one inline stepping test for arm-ubuntu. (#114295) 2024-10-31T09:06:42+00:00 jimingham jingham@apple.com 2024-10-31T09:06:42+00:00 a218f0f354e9df2ce689686be503f3d85fea44f9 The test is currently passing everywhere but this 32-bit arm ubuntu bot. I don't have an easy way to debug this, so I'm skipping the test on that platform till we get a chance to figure this out. 
The test is currently passing everywhere but this 32-bit arm ubuntu bot.
I don't have an easy way to debug this, so I'm skipping the test on that
platform till we get a chance to figure this out.
 Fix stepping away from the bottom-most frame of a virtual inlined call stack. (#114337) 2024-10-31T01:26:38+00:00 jimingham jingham@apple.com 2024-10-31T01:26:38+00:00 3243e3d8872585091d65ea7ff0639155b4c1dd7a The computation of 'Thread::IsVirtualStep" was wrong - it called being at the bottom of a virtual call stack a "virtual step" but that is actually when you've gotten to concrete code and need to step for real. I also added a test for this. 
The computation of 'Thread::IsVirtualStep" was wrong - it called being
at the bottom of a virtual call stack a "virtual step" but that is
actually when you've gotten to concrete code and need to step for real.

I also added a test for this.
 Fix call site breakpoint patch (#114158) 2024-10-30T16:28:38+00:00 jimingham jingham@apple.com 2024-10-30T16:28:38+00:00 7dbbd2b251412b7b0809aabe672f3f57f0805dbb This fixes the two test suite failures that I missed in the PR: https://github.com/llvm/llvm-project/pull/112939 One was a poorly written test case - it assumed that on connect to a gdb-remote with a running process, lldb MUST have fetched all the frame 0 registers. In fact, there's no need for it to do so (as the CallSite patch showed...) and if we don't need to we shouldn't. So I fixed the test to only expect a `g` packet AFTER calling read_registers. The other was a place where some code had used 0 when it meant LLDB_INVALID_LINE_NUMBER, which I had fixed but missed one place where it was still compared to 0. 
This fixes the two test suite failures that I missed in the PR:

https://github.com/llvm/llvm-project/pull/112939

One was a poorly written test case - it assumed that on connect to a
gdb-remote with a running process, lldb MUST have fetched all the frame
0 registers. In fact, there's no need for it to do so (as the CallSite
patch showed...) and if we don't need to we shouldn't. So I fixed the
test to only expect a `g` packet AFTER calling read_registers.

The other was a place where some code had used 0 when it meant
LLDB_INVALID_LINE_NUMBER, which I had fixed but missed one place where
it was still compared to 0.
 Revert "Add the ability to break on call-site locations, improve inli… (#113947) 2024-10-28T18:52:32+00:00 jimingham jingham@apple.com 2024-10-28T18:52:32+00:00 b54bc104ea87e301816b450ee117d2d864c7d82d …ne stepping (#112939)" This was breaking some gdb-remote packet counting tests on the bots. I can't see how this patch could cause that breakage, but I'm reverting to figure that out. This reverts commit f14743794587db102c6d1b20f9c87a1ac20decfd. 
…ne stepping (#112939)"

This was breaking some gdb-remote packet counting tests on the bots. I
can't see how this patch could cause that breakage, but I'm reverting to
figure that out.

This reverts commit f14743794587db102c6d1b20f9c87a1ac20decfd.
 Add the ability to break on call-site locations, improve inline stepping (#112939) 2024-10-28T17:01:57+00:00 jimingham jingham@apple.com 2024-10-28T17:01:57+00:00 f14743794587db102c6d1b20f9c87a1ac20decfd Previously lldb didn't support setting breakpoints on call site locations. This patch adds that ability. It would be very slow if we did this by searching all the debug information for every inlined subroutine record looking for a call-site match, so I added one restriction to the call-site support. This change will find all call sites for functions that also supply at least one line to the regular line table. That way we can use the fact that the line table search will move the location to that subsequent line (but only within the same function). When we find an actually moved source line match, we can search in the function that contained that line table entry for the call-site, and set the breakpoint location back to that. When I started writing tests for this new ability, it quickly became obvious that our support for virtual inline stepping was pretty buggy. We didn't print the right file & line number for the breakpoint, and we didn't set the position in the "virtual inlined stack" correctly when we hit the breakpoint. We also didn't step through the inlined frames correctly. There was code to try to detect the right inlined stack position, but it had been refactored a while back with the comment that it was super confusing and the refactor was supposed to make it clearer, but the refactor didn't work either. That code was made much clearer by abstracting the job of "handling the stack readjustment" to the various StopInfo's. Previously, there was a big (and buggy) switch over stop info's. Moving the responsibility to the stop info made this code much easier to reason about. We also had no tests for virtual inlined stepping (our inlined stepping test was actually written specifically to avoid the formation of a virtual inlined stack... So I also added tests for that along with the tests for setting the call-site breakpoints. 
Previously lldb didn't support setting breakpoints on call site
locations. This patch adds that ability.

It would be very slow if we did this by searching all the debug
information for every inlined subroutine record looking for a call-site
match, so I added one restriction to the call-site support. This change
will find all call sites for functions that also supply at least one
line to the regular line table. That way we can use the fact that the
line table search will move the location to that subsequent line (but
only within the same function). When we find an actually moved source
line match, we can search in the function that contained that line table
entry for the call-site, and set the breakpoint location back to that.

When I started writing tests for this new ability, it quickly became
obvious that our support for virtual inline stepping was pretty buggy.
We didn't print the right file & line number for the breakpoint, and we
didn't set the position in the "virtual inlined stack" correctly when we
hit the breakpoint. We also didn't step through the inlined frames
correctly. There was code to try to detect the right inlined stack
position, but it had been refactored a while back with the comment that
it was super confusing and the refactor was supposed to make it clearer,
but the refactor didn't work either.

That code was made much clearer by abstracting the job of "handling the
stack readjustment" to the various StopInfo's. Previously, there was a
big (and buggy) switch over stop info's. Moving the responsibility to
the stop info made this code much easier to reason about.

We also had no tests for virtual inlined stepping (our inlined stepping
test was actually written specifically to avoid the formation of a
virtual inlined stack... So I also added tests for that along with the
tests for setting the call-site breakpoints.
 [lldb] Fix Python test formatting (NFC) 2023-06-16T21:51:14+00:00 Jonas Devlieghere jonas@devlieghere.com 2023-06-16T21:48:37+00:00 ab855530f797bbc113f75f833a4ca5711749d7c8 All Python files in the LLVM repository were reformatted with Black [1]. Files inside the LLDB subproject were reformatted in 2238dcc39358. This patch updates a handful of tests that were added or modified since then and weren't formatted with Black. [1] https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style/68257 
All Python files in the LLVM repository were reformatted with Black [1].
Files inside the LLDB subproject were reformatted in 2238dcc39358. This
patch updates a handful of tests that were added or modified since then
and weren't formatted with Black.

[1] https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style/68257
Revert "[LLDB] Add/Remove xfail for some API tests on Windows" 2023-05-29T13:39:36+00:00 tcwg tcwg@linaro.org 2023-05-29T12:57:26+00:00 ab05d9134d18db34501985a01fbfc02609767587 This reverts commit 6ea1a0d4fc3823de143a288df2059b48dc01cf72. It again marks XFAIL LLDB tests failing after c384fcd3ea1dad782eaaea89b32fc33c0c3528b8 
This reverts commit 6ea1a0d4fc3823de143a288df2059b48dc01cf72.

It again marks XFAIL LLDB tests failing after
c384fcd3ea1dad782eaaea89b32fc33c0c3528b8
[NFC][Py Reformat] Reformat python files in lldb 2023-05-25T19:54:09+00:00 Jonas Devlieghere jonas@devlieghere.com 2023-05-25T15:48:57+00:00 2238dcc39358353cac21df75c3c3286ab20b8f53 This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with `black` (23.1.0). If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run `git checkout --ours <yourfile>` and then reformat it with black. RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential revision: https://reviews.llvm.org/D151460 
This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).

If you end up having problems merging this commit because you have made
changes to a python file, the best way to handle that is to run `git
checkout --ours <yourfile>` and then reformat it with black.

RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style

Differential revision: https://reviews.llvm.org/D151460