Bug 344471 - [multi-process][disassembly] Cannot show mixed-mode disassembly when using multiple different binaries
Summary: [multi-process][disassembly] Cannot show mixed-mode disassembly when using mu...
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-debug-dsf-gdb (show other bugs)
Version: 8.0   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-02 11:11 EDT by Marc Khouzam CLA
Modified: 2020-09-04 15:19 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.