"Correctly use GetLoadedModuleList to take advantage of libraries-svr4" can cause LLDB to abort

Subprojects LLDB
1

Hi Antonio,

This is in regards to https://reviews.llvm.org/D64013 , specifically this code in ProcessGDBRemote::GetImageInfoAddress:

if (addr == LLDB_INVALID_ADDRESS) {

llvm::Expected list = GetLoadedModuleList();

if (!list) {

Log *log(ProcessGDBRemoteLog::GetLogIfAllCategoriesSet(GDBR_LOG_PROCESS));

LLDB_LOG_ERROR(log, list.takeError(), “Failed to read module list: {0}”);

} else {

addr = list->m_link_map;

}

}

If LLVM_ENABLE_ABI_BREAKING_CHECKS is set to 1 (which is true when asserts are enabled), llvm::Expected will call abort() if there is an error.

GetLoadedModuleList() has many reasons to set an error, including when XML is not available, or when the stub doesn’t support remote modules.

I don’t think we ever want to crash LLDB if the remote stub doesn’t support something. I don’t think llvm::Expected is the right solution here, and I think it should be removed.

Ted

2

IIUC an llvm::Expected is only supposed to abort if you leave its scope with an un-consumed error. LLDB_LOG_ERROR is supposed to consume the error - the code looks like it is doing that. So if you are still seeing an abort when there's an error, then it sounds like something is wrong with LLDB_LOG_ERROR.

Expected is supposed to force you to check the error - by aborting if you don't - but you are free to discard the error if it is non-fatal by consuming it, and then you should not abort.

Jim