cisco-open / llvm-crash-analyzer

llvm crash analysis
Apache License 2.0
40 stars 17 forks source link

Ensure debuggee process launch when core-file is specified #50

Closed niktesic closed 1 year ago

niktesic commented 1 year ago

Description

Ensure setup of debug session when --core-file argument is used for remote debugging via lldb-crash-server. This patch fixes lldb-crash-server to launch debuggee process when core-file needs to be loaded. Confirmed that lldb-crash-server is working as debugserver with both LLDB and GDB as clients.

TODO: If debuggee process is launched, try to set the target execution context, with the information loaded from the core-file.

Type of Change

gsidhard commented 1 year ago

Hi Nikola, your code change makes a call to handle_launch() followed by a call to handle_core() when the --core-file argument is supplied. This means that handle_launch() will create a new process as the inferior to the lldb-(crash)-server, and subsequently we will read in the core.

Is this what we really want? As far as I understand, we should not be creating a new process, but will need to create a synthetic process with the values read in from the core file.

My own investigation in the same area took me in a totally different direction - it involves initialising the member variable GDBRemoteCommunicationServerLLCS::m_current_process with the pid, tids, etc. read in from the core file. I will let Ali and Ananth comment on which is the approach to be taken.

niktesic commented 1 year ago

Hi Nikola, your code change makes a call to handle_launch() followed by a call to handle_core() when the --core-file argument is supplied. This means that handle_launch() will create a new process as the inferior to the lldb-(crash)-server, and subsequently we will read in the core.

Is this what we really want? As far as I understand, we should not be creating a new process, but will need to create a synthetic process with the values read in from the core file.

My own investigation in the same area took me in a totally different direction - it involves initialising the member variable GDBRemoteCommunicationServerLLCS::m_current_process with the pid, tids, etc. read in from the core file. I will let Ali and Ananth comment on which is the approach to be taken.

Hi Gopi, I didn't think in that direction. My idea was to start inferior process and then explicitly set the context with the info from the core-file. Although, I am not sure if that is possible. Is your approach what GDB/LLDB does when debugging core-files regularly?

niktesic commented 1 year ago

Both GDB and LLDB create an internal debuggee process straight from the core-file, so it is better to follow this approach and abandon this PR.