Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] module specific source lookup

The module returned by IFRameDMData is a convenience method.  More complete module information should be retrieved using the IModules service.  That said, I think it makes more sense to return a full path, and let the UI code shorten it.  Please file a bug for the UI to handle a full path being returned IFrameDMData.getModule().

Thanks,
Pawel

Alexiev, Dobrin wrote:

I agree with you, Pawel,

 

It makes sense for these soruce lookup entries to be stored globally or/and per project.

I’ll follow Mikhail’s advice to create custom source lookup container.

 

I also have a question about one of the DSF APIs:

Should IFrameDMData.getModule() return a short name or it can return a full path to the module file?

I see the API is used to for display purpose, in which case very long names may clutter the UI.

 

Thanks

Dobrin

 


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
Sent: Friday, May 29, 2009 1:06 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] module specific source lookup

 

Hi Alex,
I think this use case is somewhat similar to the one that John brought up in this thread.  I.e. it would be nice if source lookup settings could be associated with other entities besides the launch configuration.  For example in this case, it would be better to create source lookup settings for each module and store them with project data.

Short of this, I agree with mikhail that you'll need custom source lookup containers and custom source lookup participant, which will take into account the module in addition to the source file name.

Cheers,
Pawel

Alexiev, Dobrin wrote:

Hello, 
 
I am in the process of integrating our backend debugger in Eclipse using the DSF framework. Here is one use case I need to satisfy. 
 
The user is debugging a program that has multiple modules (DLLs, shared objects). Each of the modules (DLLs, shared objects) is compiled separately - the source files for that module are in their own directory structure. 
 
Most importantly - the names of the source files compiled into different modules can be the same but they really are different files. For example "main.c" can appear in many modules. 
 
The user suspends the program. The Debug View shows stack frames from different modules. Some of the frames point to a source files with the same name - "main.c" but different module. 
 
The debugger will properly identify which "main.c" is from which directory structure because the module name plus the source file name will uniquely identify the location of the source file. 
 
In some cases the OUT file can be moved away from the location it was built. In these cases the user will be prompted to specify the path to one of the source files for that module. The rest of the source files will be found automatically. The information the user entered will be specific for that module and won't be used to perform source lookup for other modules. 
 
I think the main idea here is: A soruce location is based not only on source file name but also on module name. That will provide more accurate information to perform source lookup. 
 
If other people think this approach for source lookup makes sense and will benefit other users, I could open a Bugzilla entry and further discuss the requirements, design and implementation for this use case. 
 
Thanks
Dobrin
 
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
  

 


_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top