After #167359 / 95db31e7f69e7008f0c570ed30d54d1e418e10f2. A fix was attempted in #167423 but was not quite enough. From what I could understand, in v1 format you have to specify all the basic blocks. Where before !call_me implied they were all cold (I think, very shaky understanding here). For this test we want to see blocks like call_me/foo/call_me. So adding a line for block 1 fixes the tests. It could produce more blocks at some point but I think as long as foo is within two of them, it'll be fine.
`INSERT BEFORE` keyword is not supported in current versions gold and mold linkers. Since we cannot confirm accurately what linker and version is available on the system and when it will be supported. We test it with a sample program using the script keywords.
The implementation has an optimization which detects the range of line table entries covered by the function and then only searches for a matching line between them. This optimization was interfering with the logic for detecting whether a line belongs to the function because the first call to FindLineEntry was made with exact=false, which meant that if the function did not contain any exact matches, we would just pick the closest line number in that range, even if it was very far away. This patch fixes that by first attempting an inexact search across the entire line table, and then use the (potentially inexact) result of that for searching within the function. This makes the optimization a less effective, but I don't think we can differentiate between a line that belongs to the function (but doesn't have any code) and a line outside the function without that. The patch also avoids the use of (deprecated) Function::GetAddressRange by iterating over the GetAddressRanges result to find the full range of line entries for the function.
The compiler does not support this feature on other architectures.
I think the only issue here was that we would erroneously consider functions which are "in the middle" of the function were stepping to as a part of the function, and would try to step into them (likely stepping out of the function instead) instead of giving up early.
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
The requirements for "thread until <line number>" are: a) If any code contributed by <line number> or the nearest subsequent of <line number> is executed before leaving the function, stop b) If you end up leaving the function w/o triggering (a), then stop In case of (a), since the <line number> may have multiple entries in the line table and the compiler might have scheduled/moved the relevant code across, and the lldb does not know the control flow, set breakpoints on all the line table entries of best match of <line number> i.e. exact or the nearest subsequent line. Along with the above, currently, CommandObjectThreadUntil is also setting the breakpoints on all the subsequent line numbers after the best match and this latter part is wrong. This issue is discussed at http://lists.llvm.org/pipermail/lldb-dev/2018-August/013979.html. In fact, currently `TestStepUntil.py` is not actually testing step until scenarios and `test_missing_one` test fails without this patch if tests are made to run. Fixed the test as well. Reviewed By: jingham Differential Revision: https://reviews.llvm.org/D50304
This reverts commit a57b62deef37c7f2ec31bca3bf9173a6206bfb9b. lldb-aarch64-ubuntu buildbot test fails since https://lab.llvm.org/buildbot/#/builders/96/builds/25128
The requirements for "thread until <line number>" are: a) If any code contributed by <line number> or the nearest subsequent of <line number> is executed before leaving the function, stop b) If you end up leaving the function w/o triggering (a), then stop In case of (a), since the <line number> may have multiple entries in the line table and the compiler might have scheduled/moved the relevant code across, and the lldb does not know the control flow, set breakpoints on all the line table entries of best match of <line number> i.e. exact or the nearest subsequent line. Along with the above, currently, CommandObjectThreadUntil is also setting the breakpoints on all the subsequent line numbers after the best match and this latter part is wrong. This issue is discussed at http://lists.llvm.org/pipermail/lldb-dev/2018-August/013979.html. In fact, currently `TestStepUntil.py` is not actually testing step until scenarios and `test_missing_one` test fails without this patch if tests are made to run. Fixed the test as well. Reviewed By: jingham Differential Revision: https://reviews.llvm.org/D50304