R_RISCV_ALIGN semantics .

[Umesh Kalappa]

Thank you Jim and Palmer for suggestions ,

Yes,we are going with -mno-relax" for now .

~Umesh

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Wed, Aug 5, 2020 at 4:14 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:

> On Sun, 02 Aug 2020 21:30:00 PDT (-0700), Jim Wilson wrote:
> > On Fri, Jul 31, 2020 at 1:32 AM Umesh Kalappa via Binutils
> > <binutils@sourceware.org> wrote:
> >> We have loadable kernel module for our custom OS ,where we do partial
> >> linking and  by default LLVM enable relaxation for RISCV  and for some
> >> instance we need to enable relaxation and need to get rid of
> R_RISCV_ALIGN
> >> relocs and for other relocs we just patch the address and don't do any
> code
> >> size linker optimisations .
> >
> > The easy solution is to disable relaxation for loadable kernel
> > modules.  This is what linux does.
>
> Specifically: if you're not indenting on relaxing in your linker then
> "-mrelax"
> only hurts you, and you should use "-mno-relax" instead.  There's nothing
> really specific to kernel module loaders here -- we could support
> relaxation in
> the Linux module loader, it's just that nobody has gotten around to it.
>
> If you're writing your own OS then you probably have way more important
> problems to solve than linker relaxation for loadable kernel modules, so
> "-mno-relax" seems like the only sane way to go to me.
>
> >> So given this scenario ,we are trying to address the R_RISCV_ALIGN
> reloc at
> >> load time and currently we are patching the nop with pad value like
> default
> >> zero or any value .
> >>
> >> patching pad values is the right R_RISCV_ALIGN  semantics  in our
> scenario ?
> >
> > If relaxation is enabled, and you have an align operation, then gas
> > emits the maximum possible number of nops that might be required to
> > align the code.  Then at link time, after all other relaxable
> > relocations have been resolved, then the linker deletes the excess
> > nops, starting with the lowest address and moving up to the highest
> > address, so that everything is correctly aligned when done.  You can
> > not do any relaxations that reduce code size after handling
> > R_RISCV_ALIGN, as then the code will become unaligned again.
> >
> > If relaxation is disabled, and you have an align operation, then gas
> > assumes there will be no code size changes at link time and emits the
> > right number of nops to align the code.  In this case, there is
> > nothing for the linker to do to get correct alignment, as we already
> > have correct alignment coming out of the assembler.
> >
> > Jim
>