Re: [Xen-devel] [RFC 6/7] arm: Introduce dummy empty functions for data only C files

[Artem Mygaiev <Artem_Mygaiev@xxxxxxxx>]

Hello Julien

On Thu, 2019-11-14 at 08:03 +0900, Julien Grall wrote:
> 
> 
> On Tue, 12 Nov 2019, 05:57 Stefano Stabellini, <
> sstabellini@xxxxxxxxxx> wrote:
> > On Wed, 6 Nov 2019, Andrii Anisov wrote:
> > > From: Andrii Anisov <andrii_anisov@xxxxxxxx>
> > > 
> > > ARM Compiler 6 has a proven bug: it compiles data only C files
> > with
> > > SoftVFP attributes. This leads to a failed linkage afterwards
> > with
> > > an error:
> > > 
> > > Error: L6242E: Cannot link object built_in.o as its attributes
> > are incompatible with the image attributes.
> > > ... A64 clashes with SoftVFP.
> > > 
> > > The known workaround is introducing some code into the affected
> > file,
> > > e.g. an empty (non-static) function is enough.
> > 
> > Oh man, this is truly horrible.
> > 
> > If we really have to do this please:
> > 
> > - use the same dummy function name in all files
> > - the function should be static
> > - hiding the function within a #ifdef ARMCC block
> > - potentially hide the whole horrible hack behind a #define so that
> > it
> >   would become at the call site:
> > 
> >  +ARMCC_DUMMY_FUNC_HACK()
> 
> 
> The risk here is we may introduce new file in the future possibly in
> common code with similar issues. So I would prefer if we can find an
> automatic way to do this. Some ideas:
>     - Add the function at compile time (via makefile). This would be
> done for all the files but that's should not be a major issues.
>     - Force disable softfvp either via command line, new line in the
> code or rewriting the attribute of the object.
> 
> But before spending time trying to workaround a buggy compiler.
> What's the plan with it? Is it going to be used in production or just
> a demo?

This is not intended for a production program at the moment, and it
obviously require lot of further work. I would not try to upstream ugly
workarounds for issues like the one above, it would be much better to
somehow persuade Arm tools team to properly fix them.

This RFC series has following goals:
1) prove that we can use safety-certified tools for Xen and avoid
possible arguments on compiler/linker certification path
2) research possible issues when using non-standard compiler/linker and
try to see if it is easy to adjust Xen to use them

In the end, it would be great to make Xen build system flexible enough
to use with non-standard compilers without overcomplicating it or changing it 
significantly, causing too much disruption to community.

> Cheers,
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxx
> 
> https://urldefense.com/v3/__https://lists.xenproject.org/mailman/listinfo/xen-devel__;!K6dmGCEab4ueJg!kCpXu2prtUxCHZV8aCvxYk9E82KnsHuNftyCeG745Ei3vhO2VP_SYXDnItHeZZCwdw$
>  
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel