This patch is causing a test to fail internally. I have provided the details to the author.

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.

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.

Added LLDB_REGISTER_METHOD for GetDescription.

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

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.

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.

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.

Thank you for the review and suggestion to check memory region.

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.

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.

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.

Reverted code changes from ObjectFileELF as suggested and added directly to DYLDRendezvous.cpp.

fork is being called in LaunchProcess function in this file(ProcessLauncherPosixFork.cpp) itself.

Ping.

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:

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.

LGTM

LGTM

Removed the extra parenthesis.

@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.

Thanks for the review! I will check them in as two separate commits.

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.

It seems that following tests are broken with this change:

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.

LGTM

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?

LGTM