Re: [trunk+v3] Thumb and interworking manipulation goals

[John Dallaway <john at dallaway dot org dot uk>]

Hi Bart

Bart Veer wrote:

>>>>>> "John" == John Dallaway <john@dallaway.org.uk> writes:
> 
>     John> This patch merges goals for CYGHWR_THUMB and
>     John> CYGBLD_ARM_ENABLE_THUMB_INTERWORK to allow selective
>     John> application of CDL solutions within the eCos Configuration
>     John> Tool. Workaround for Bugzilla 1000707. Checked-in.
> 
> I am not sure why this is necessary. Enabling/disabling thumb mode or
> interwork support should update CYGBLD_ARCH_CFLAGS and
> CYGBLD_ARCH_LDFLAGS, and all ARM targets should be using those for the
> default_value's of CYGBLD_GLOBAL_CFLAGS and CYGBLD_GLOBAL_LDFLAGS. So
> normally the flags would update automatically, the constraints would
> be satisfied, and there is no need for the configtool or the user to
> worry about any of this.

Yes, there's no problem when CYGBLD_GLOBAL_CFLAGS and
CYGBLD_GLOBAL_LDFLAGS have the default value source.

> The only scenario I can think of where this might be a problem is if a
> user starts editing CYGBLD_GLOBAL_CFLAGS or CYGBLD_GLOBAL_LDFLAGS, and
> only then manipulates the thumb and interwork settings. Is that worth
> worrying about?

I think it _is_ worth addressing this issue on usability grounds. It is
not uncommon for (eg) CYGBLD_GLOBAL_CFLAGS to have a user_value due to a
change in compiler optimisation level. The purpose of the CDL goals in
question is to ensure that such a user_value is updated correctly when
CYGHWR_THUMB, CYGBLD_ARM_ENABLE_THUMB_INTERWORK or
CYGHWR_HAL_ARM_BIGENDIAN are changed. Prior to this patch, ConfigTool
would present multiple incomplete solutions for the same CDL item if
more than one of these options were changed within the same CDL transaction.

> The older version of the CDL managed it all with just eight lines of
> constraints. The new version requires fourteen, and personally I find
> it less clear. It is not a big deal, but I would just like to
> understand why the change is necessary.

I agree that the change is not elegant. It is just a workaround pending
a better solution within the host tools. The multiple solutions
described should really be merged into a single solution - either within
ConfigTool or at the libCDL level.

John Dallaway