R_RISCV_ALIGN semantics .

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

R_RISCV_ALIGN semantics .

Sourceware - binutils list mailing list
Hi All,

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 .

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 ?

Thank you
~Umesh
Reply | Threaded
Open this post in threaded view
|

Re: R_RISCV_ALIGN semantics .

Jim Wilson-2
On Fri, Jul 31, 2020 at 1:32 AM Umesh Kalappa via Binutils
<[hidden email]> 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.

> 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
Reply | Threaded
Open this post in threaded view
|

Re: R_RISCV_ALIGN semantics .

Palmer Dabbelt
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
> <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: R_RISCV_ALIGN semantics .

Sourceware - binutils list mailing list
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 <[hidden email]> 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
> > <[hidden email]> 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
>