Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Problem with sharing launch attributes

> I think we should just implement in CDI-GDB same 
> functionality for core file (take if not null and prompt if null).

CDI-GDB kind of does this already.  The problem is that there is no
text box to enter the core file.  So, if DSF-GDB sets an invalid value
and we move the launch to a CDI-GDB one, there is no way to modify this.

But maybe you are suggesting to add a text box to the CDI-GDB launch?

> 
> Marc Khouzam wrote:
> > Hi,
> > 
> > the new launch system that handles both CDI-GDB and DSG-GDB 
> brings up an
> > interesting
> > situation.  Basically, a launch can be converted from 
> CDI-GDB to DSF-GDB
> > and vice-versa.
> > This can cause a problem because the two types of launches 
> share launch
> > attributes, but
> > don't always use them in the same way.
> > 
> > For example, for the PostMortem launch, DSF-GDB sets 
> > ICDTLaunchConfigurationConstants.ATTR_COREFILE_PATH so as 
> to remember
> > the core file
> > between launches.  This is incompatible with CDI-GDB which 
> requires that
> > attribute
> > to be null.  I opened
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=273833
> > about this.
> > 
> > I have two questions:
> > 
> > 1- Is there some platform support in the launch 
> infrastructure to allow
> > for a 
> > 'transformation' that I could provide?  Something that 
> would run when a
> > launch
> > is converted one type to another.  In that code, I could null 
> > ICDTLaunchConfigurationConstants.ATTR_COREFILE_PATH, when going to a
> > CDI-GDB launch.
> > I think this is the best solution, because this problem 
> could arise for
> > any attribute
> > that is shared.
> > 
> > 2- Is there a reason for the 'trick' used by CDI-GDB in its use of 
> > ICDTLaunchConfigurationConstants.ATTR_COREFILE_PATH?
> > Basically, the launch reads this attribute, if it null it 
> prompts for a
> > core file,
> > then sets the attributes, then triggers a *new* launch, and finally
> > resets the
> > attribute to null.
> > I was thinking that we could simply always prompts and 
> thus, not require
> > the
> > attribute to be null. But I don't know if there is reason 
> for CDI-GDB to
> > 
> > base itself on the attribute being null or not to trigger the prompt
> > (maybe to 
> > allow for automated testing, or some manual debugging?)
> > 
> > Thanks
> > 
> > Marc
> > _______________________________________________
> > 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