Re: [Xen-devel] [RFC 5/7] WIP:arm64:armds: Build XEN with ARM Compiler 6.6

[Julien Grall <julien@xxxxxxx>]

Hi Andrii,

On 14/11/2019 11:31, Andrii Anisov wrote:
> On 13.11.19 07:50, Julien Grall wrote:
> > To be honest, I don't think this file should even exist. This looks 
> > like a copy of xen.lds.S with a different syntax.
> And lacking features like symbols definition, current address setup, etc.
That's fine, you can introduce macro that will just be a NOP for 
armlinker and implemented for ld.
> > Furthermore, the comments from Stefano shows that is going to be hard 
> > to maintain/check everything has been written correctly.
> It will be terribly hard.
>
> > So how about trying to abstract xen.lds.S?
> I failed to find the common ground for them.
> You are very welcomed to suggest that piece of code.
I don't have time to work on the full feature, but I can provide a few 
ideas so you can implement it.
If we look at the .text section. For the GNU linker script, it is:

  _start = .;
  .text : {
        _stext = .;            /* Text section */
       *(.text)
       *(.text.cold)
       *(.text.unlikely)
       *(.fixup)
       *(.gnu.warning)
       _etext = .;             /* End of text section */
  } :text = 0x9090

For armds, you implement as

;_start
;_stext
  _text AlignExpr(+0, PAGE_SIZE) PADVALUE 0x9090
  {
    *(.text*)
    *(.text.cold)
    *(.text.unlikely)
    *(.fixup)
    *(.gnu.warning)
  }
;_etext

You could imagine the following abstraction:

SYMBOL(_start)
SECTION(_text)
  SYMBOL(_stext)
  *(.text)
  *(.text.cold)
  *(.text.unlikely)
  *(.fixup)
  *(.gnu.warning)
  SYMBOL(_etext)
ESECTION(text)

For GNU linker scripts, the macros would be implemented as

#define SYMBOL(sym) sym := .;
#define SECTION(sect) sect : {
#define ESECTION(phdr) } :phdr = 0x9090


For the Arm scatter file, the macros would be implemented as

/* Symbols are not declared in the scatter file */
#define SYMBOL(sym) ;sym
#define SECTION(sect) sect AlignExpr(+0, PAGE_SIZE) PADVALUE 0x9090 {
#define ESECTION(phdr) }

A few caveats:
   - I am not entirely sure why we specific the pading value only for 
.text and not the other. I also don't understand the 0x9090 value. 
Stefano? It may be possible to remove this completely.
   - The alignment could be passed as a parameter for the macro
   - The linker script may need some reshuffle in order to make it generic.

On a side note, I noticed that you are using *(.text*), rather than 
*(.text). Could you explain why?
> >      > +/*
> >      > + * armlink does not understand shifts in scat file expressions
> >      > + * so hardcode needed values
> >      > + */
> >
> >
> > Please give a pointer to the doc of the armlink in the commit message. 
> > So we can easily cross-check what's happening.
> The best cross-check would be running the compiler. Yet, this particular 
> thing is somehow documented [1].
> > In this case, I don't particularly like the re-definition of the 
> > defines outside of their header. This is going to make more difficult 
> > if we have to update them in the future.
> > I can see a few ways to do it:
> >
> >   - Avoid using shifts in the definitions
> >   - Find a way to evaluate the value (maybe similar to asn-offset) 
> > before using them.
> > My preference would be the latter but I could be convinced for the 
> > former.
> The first option is not realistic. I suggested ARM to consider shifts 
> support as an improvement for their compiler.
> I'd be very happy to adopt the second option. Do you have any code 
> examples or hints how to evaluate expressions on the pre-processing stage?
I wasn't thinking to do it a pre-processing state but rather generating 
an header that will have the value already computed.
Have a look at how we generate defininition for assembly (see 
arch/arm32/asm-offsets.c).
Looking at the link you provided, I noticed that * is supported by the 
scatter file. So it might be possible to introduce a macro LSHIFT(a, b) 
that will be implemented as a << b or (a * a * a ...) depending on the 
users. The major difficulty here would be to find a way to generate a * 
a * a... nicely during pre-processing.
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel