[ECOS] Re: uSTL hello world
Jonathan Larmour
jifl@jifvik.org
Tue Sep 29 15:36:00 GMT 2009
Bart Veer wrote:
>>>>>>"Jifl" == Jonathan Larmour <jifl@jifvik.org> writes:
>
>
> <snip>
>
> Jifl> Unfortunately we have another problem. I've looked at the
> Jifl> output of our recent compilers, and I see that
> Jifl> CYG_REFERENCE_OBJECT no longer appears to be effective :-(.
[snip failed attempts to resolve]
> Jifl> Any other ideas? At least there are not many uses of
> Jifl> CYG_REFERENCE_OBJECT.
>
> I think the following may do the trick:
>
> ----------------------------------------------------------------------------
> // The unused attribute stops the compiler warning about the variable
> // not being used.
> // The used attribute prevents the compiler from optimizing it away.
>
> #define NEW_CYG_REFERENCE_OBJECT(__object__) \
> CYG_MACRO_START \
> static const void* __cygvar_discard_me__ \
> __attribute__ ((unused, used)) = (const void*)&(__object__); \
> CYG_MACRO_END
> ----------------------------------------------------------------------------
>
> I have tried it in a simple testcase at -O2. The compiler does not
> optimize away __cygvar_discard_me__ because the used attribute
> prevents that. Hence the referenced object gets pulled in during the
> link. Subsequently linker garbage collection eliminates
> __cygvar_discard_me__. If the referenced object is a C++ object then
> it will be preserved because of the KEEP(*.ctors) in the linker
> script. So, even though it seems peculiar to have a variable both used
> and unused, that combo appears to do what we want and should be fully
> portable.
That does seem very peculiar, but if it works....
> Looking at the gcc ChangeLog-2001, attribute(used) was added on
> 2001-10-18 so has probably been available since gcc 3.1 days. However
> there is a comment in cyg_type.h associated with CYGBLD_ATTRIB_USED
> claiming >= 3.3.2.
ISTR something about the behaviour of that attribute changing at some
point- perhaps it was buggy before. We could ifdef CYG_REFERENCE_OBJECT
based on GCC version easily enough.
> Let me know if it still does not solve the problem in al cases, and I
> can investigate further.
Now I think it's back to Uwe to verify that this, in combination with the
stuff I mentioned before, does resolve his uSTL problems.
Uwe?
Even better if you can submit an associated patch.
Jifl
--
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss
mailing list