User Details
- User Since
- Feb 28 2018, 1:50 PM (226 w, 5 d)
Jan 4 2022
This patch is causing a test to fail internally. I have provided the details to the author.
Sep 10 2021
With this patch, it looks like the test added in this patch fails for lldb-arm-ubuntu:
https://lab.llvm.org/buildbot/#/builders/17/builds/10498
@teemperor: I believe I have addressed your comments. If there is any other concern, I can address it post-commit.
Sep 9 2021
Thanks Pavel for investigating and figuring out that the upstream failing test had libxml support disabled. I was able to reproduce the failure locally by adding -DLLDB_ENABLE_LIBXML2=False to cmake.
Updated UpdateFileSpecIfNecessary function to only update filename if the region.GetName().AsCString() is not empty, which checks for both null and empty.
Sep 8 2021
Sep 3 2021
Added LLDB_REGISTER_METHOD for GetDescription.
Sep 2 2021
Thank you for suggestion to try!
After adding the assertions in memory region info trick, 3 testcases from only one test failed because of assertion : lldb/test/API/functionalities/load_unload/TestLoadUnload.py
Sep 1 2021
Thank you for giving it a try! It passes for me for both Release and RelWithDebInfo along with asserts enabled in each case. I can give it a try by recommitting and checking the status, this patch is in Needs Review status presently. Hence, requesting for a review.
Aug 30 2021
For me, this test passes every time. I have tried multiple times with instructions from failing bot, but haven't been able to reproduce the failure locally yet.
Aug 27 2021
Aug 26 2021
This patch caused a test failure when it was submitted two days ago, so I reverted it that day. However, I have not been able to reproduce the failure locally even using the cmake config from bot.
Aug 24 2021
Thank you for the review and suggestion to check memory region.
Aug 19 2021
Updated to extract executable file name using GetMemoryRegionInfo since ld.so returns empty file name for executable file name.
Looking further as to why executable symbols are not loaded, it looks like when we read the link_map in lldb, AddSOEntries() is called for all the entries in link_map read from ld.so. The first entry's name(which corresponds to executable) is empty, which seems to be set by ld.so here (https://github.com/bminor/glibc/blob/master/elf/rtld.c#L1389). main_map at this location has the entry for respective executable, but its name is removed, hence lldb while going through entries can't read entry about main executable.
Aug 18 2021
Updated comments as suggested.
I checked the status with both gdb and lldb using test case added here. It looks like breakpoint on main doesn't get hit even for gdb when called through ld.so. However, breakpoint on shared library functions is supported by gdb. With this patch, we are now able to set breakpoint on functions in shared libraries as supported by gdb.
Aug 17 2021
Updated it to use llvm's filesystem.
Updated the test to check for the respective function name from the shared library in the frames.
I didn't add run_to_source_breakpoint since we can't set a breakpoint on main initially before running the program. Hence it would need to be run first and then we can check later to see if the function name is available. Please let me know if you think there is any concern with this way.
Updated the test to check for the respective function name from the shared library in the frames.
Aug 16 2021
Reverted code changes from ObjectFileELF as suggested and added directly to DYLDRendezvous.cpp.
Aug 13 2021
Aug 12 2021
fork is being called in LaunchProcess function in this file(ProcessLauncherPosixFork.cpp) itself.
Aug 11 2021
Jul 21 2021
Ping.
Jul 13 2021
Jul 9 2021
Apr 8 2021
This change is causing a difference in 2 dwarfdump statistics for a large binary with fission=yes.
After moving the variable InlinedFnsToBeProcessed to inside the for loop, I noticed a difference in two dwarfdump statistics for a quite large binary with fission=yes:
Apr 7 2021
Apr 6 2021
This patch seems to be causing a slowdown while running dwarfdump --statistics. It looks like more than 50% of the time is spent in collectZeroCovInlinedVars function.
Feb 9 2021
Apr 20 2020
Mar 10 2020
Dec 18 2019
LGTM
Dec 11 2019
Dec 9 2019
LGTM
Sep 23 2019
Removed the extra parenthesis.
Jun 28 2019
@rovka : There is one more instance of similar code in function translateInvoke around line 1670. I think you will need to update that as well.
Jun 27 2019
Jun 25 2019
Mar 28 2019
Thanks for the review! I will check them in as two separate commits.
Oct 3 2018
Sep 19 2018
Confirmed that reverting the change locally fixes the test. Could you please take a look.
It seems that following test is broken with this change: llvm/unittests/IR/PassBuilderCallbacksTest.cpp
Thanks for the fix!
It seems that following test is broken with this change: DebugInfo/WebAssembly/dbg-value-live-interval.ll
Confirmed that reverting the change locally fixes the tests. Could you please take a look.
It seems that following test is broken with this change: DebugInfo/WebAssembly/dbg-value-live-interval.ll
Confirmed that reverting the change locally fixes the tests. Could you please take a look.
Sep 18 2018
It seems that following tests are broken with this change:
Jul 31 2018
Jun 19 2018
I just saw that the change is reverted already. Thanks!
It seems that this change causes two clang tests to fail since they didn't expect this warning.
Jun 14 2018
Jun 13 2018
Jun 8 2018
What is the expected behavior for casting float values in range (-1.0 , 0.0) from float->int->float? If the expected value is -0.0 (instead of 0.0), what is the reason for that?
May 24 2018
LGTM