Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 344471

Summary: [multi-process][disassembly] Cannot show mixed-mode disassembly when using multiple different binaries
Product: [Tools] CDT Reporter: Marc Khouzam <marc.khouzam>
Component: cdt-debug-dsf-gdbAssignee: Project Inbox <cdt-debug-dsf-gdb-inbox>
Status: NEW --- QA Contact: Jonah Graham <jonah>
Severity: normal    
Priority: P3 CC: cdtdoug, nicolas.blanc, pawel.1.piech
Version: 8.0   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Whiteboard:

Description Marc Khouzam CLA 2011-05-02 11:11:24 EDT 
When debugging multiple different binaries, we fail to properly show the source code in the Disassembly view.

I can see the following error on the second process:

!ENTRY org.eclipse.cdt.dsf.ui 2 0 2011-05-02 11:05:02.379
!MESSAGE Unable to locate file: ../src/Consumer.cpp

My guess is that the relative path is taken with respect to the first binary instead of the second.  I will dig deeper.

To reproduce:
0- update to HEAD to get the changes committed yesterday
1- start a non-stop debug session with GDB >= 7.2
2- press the connect button and choose the New... button
3- create a second process using a different binary
4- show the mixed-mode Disassembly for the second process
=> The error is seen in the log.
Comment 1 Marc Khouzam CLA 2011-05-02 16:08:43 EDT 
The problem seems to be related to source-lookup and Bug 335325.  Source-lookup is not ready for multi-process.  However, it is being used to show the source code in the Disassembly view, which is why things don't work for multi-process.

Workaround:
----------
in the launch in the source tab add a "File System Directory" container for the location of the source code for the second process.

I'm guessing that if the two binaries use files with the same name, we will get a conflict, but for file that are unique to a binary, this workaround seems to work.

Fixing the source-lookup properly requires too much work (I think) for Indigo, so the workaround will have to do for now.