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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

+ fusa-sig

On Thu, 14 Nov 2019, Artem Mygaiev wrote:
> 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.

I am aligned with you on the goals.

On this specific issue, it would be great if Arm fixed their compiler.
Maybe we could discussed this problem with the Arm folks during one of
the next FuSa calls (list in CC).

_______________________________________________
Fusa-sig mailing list
Fusa-sig@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/fusa-sig