RISC-V: Resolve the issue of loadable module on 64-bit

These patches resolve the some issues of loadable module.
- symbol out of ranges
- unknown relocation types

The reference of external variable and function symbols cannot exceed 32-bit offset ranges in kernel module. The module only can work on the 32-bit OS or the 64-bit OS with sv32 virtual addressing.

These patches will generate the .got, .got.plt and .plt sections during loading module, let it can refer to the symbol which locate more than 32-bit offset. These sections depend on the relocation types:
- R_RISCV_GOT_HI20
- R_RISCV_CALL_PLT

These patches also support more relocation types
- R_RISCV_CALL
- R_RISCV_HI20
- R_RISCV_LO12_I
- R_RISCV_LO12_S
- R_RISCV_RVC_BRANCH
- R_RISCV_RVC_JUMP
- R_RISCV_ALIGN
- R_RISCV_ADD32
- R_RISCV_SUB32

Zong Li (11):
RISC-V: Add sections of PLT and GOT for kernel module
RISC-V: Add section of GOT.PLT for kernel module
RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
RISC-V: Support CALL relocation type in kernel module
RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
RISC-V: Support ALIGN relocation type in kernel module
RISC-V: Support ADD32 relocation type in kernel module
RISC-V: Support SUB32 relocation type in kernel module
RISC-V: Enable module support in defconfig
RISC-V: Add definition of relocation types

 arch/riscv/Kconfig                  |   5 ++
 arch/riscv/Makefile                 |   3 +
 arch/riscv/configs/defconfig        |   2 +
 arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
 arch/riscv/include/uapi/asm/elf.h   |  24 +++++
 arch/riscv/kernel/Makefile          |   1 +
 arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
 arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
 arch/riscv/kernel/module.lds        |   8 ++
 9 files changed, 480 insertions(+), 6 deletions(-)
 create mode 100644 arch/riscv/include/asm/module.h
 create mode 100644 arch/riscv/kernel/module-sections.c
 create mode 100644 arch/riscv/kernel/module.lds

--
2.16.1

These patches resolve the some issues of loadable module.
- symbol out of ranges
- unknown relocation types

The reference of external variable and function symbols cannot exceed 32-bit offset ranges in kernel module. The module only can work on the 32-bit OS or the 64-bit OS with sv32 virtual addressing.

These patches will generate the .got, .got.plt and .plt sections during loading module, let it can refer to the symbol which locate more than 32-bit offset. These sections depend on the relocation types:
- R_RISCV_GOT_HI20
- R_RISCV_CALL_PLT

These patches also support more relocation types
- R_RISCV_CALL
- R_RISCV_HI20
- R_RISCV_LO12_I
- R_RISCV_LO12_S
- R_RISCV_RVC_BRANCH
- R_RISCV_RVC_JUMP
- R_RISCV_ALIGN
- R_RISCV_ADD32
- R_RISCV_SUB32

Zong Li (11):
RISC-V: Add sections of PLT and GOT for kernel module
RISC-V: Add section of GOT.PLT for kernel module
RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
RISC-V: Support CALL relocation type in kernel module
RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
RISC-V: Support ALIGN relocation type in kernel module
RISC-V: Support ADD32 relocation type in kernel module
RISC-V: Support SUB32 relocation type in kernel module
RISC-V: Enable module support in defconfig
RISC-V: Add definition of relocation types

 arch/riscv/Kconfig                  |   5 ++
 arch/riscv/Makefile                 |   3 +
 arch/riscv/configs/defconfig        |   2 +
 arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
 arch/riscv/include/uapi/asm/elf.h   |  24 +++++
 arch/riscv/kernel/Makefile          |   1 +
 arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
 arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
 arch/riscv/kernel/module.lds        |   8 ++
 9 files changed, 480 insertions(+), 6 deletions(-)
 create mode 100644 arch/riscv/include/asm/module.h
 create mode 100644 arch/riscv/kernel/module-sections.c
 create mode 100644 arch/riscv/kernel/module.lds

These patches resolve the some issues of loadable module.
- symbol out of ranges
- unknown relocation types

The reference of external variable and function symbols cannot exceed 32-bit offset ranges in kernel module. The module only can work on the 32-bit OS or the 64-bit OS with sv32 virtual addressing.

These patches will generate the .got, .got.plt and .plt sections during loading module, let it can refer to the symbol which locate more than 32-bit offset. These sections depend on the relocation types:
- R_RISCV_GOT_HI20
- R_RISCV_CALL_PLT

These patches also support more relocation types
- R_RISCV_CALL
- R_RISCV_HI20
- R_RISCV_LO12_I
- R_RISCV_LO12_S
- R_RISCV_RVC_BRANCH
- R_RISCV_RVC_JUMP
- R_RISCV_ALIGN
- R_RISCV_ADD32
- R_RISCV_SUB32

Zong Li (11):
RISC-V: Add sections of PLT and GOT for kernel module
RISC-V: Add section of GOT.PLT for kernel module
RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
RISC-V: Support CALL relocation type in kernel module
RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
RISC-V: Support ALIGN relocation type in kernel module
RISC-V: Support ADD32 relocation type in kernel module
RISC-V: Support SUB32 relocation type in kernel module
RISC-V: Enable module support in defconfig
RISC-V: Add definition of relocation types

 arch/riscv/Kconfig                  |   5 ++
 arch/riscv/Makefile                 |   3 +
 arch/riscv/configs/defconfig        |   2 +
 arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
 arch/riscv/include/uapi/asm/elf.h   |  24 +++++
 arch/riscv/kernel/Makefile          |   1 +
 arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
 arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
 arch/riscv/kernel/module.lds        |   8 ++
 9 files changed, 480 insertions(+), 6 deletions(-)
 create mode 100644 arch/riscv/include/asm/module.h
 create mode 100644 arch/riscv/kernel/module-sections.c
 create mode 100644 arch/riscv/kernel/module.lds

Signature · 7 lines

2.16.1


_______________________________________________
linux-riscv mailing list
linux-riscv at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Quoted 40 lines · zong at andestech.com

These patches resolve the some issues of loadable module.
- symbol out of ranges
- unknown relocation types

The reference of external variable and function symbols cannot exceed 32-bit offset ranges in kernel module. The module only can work on the 32-bit OS or the 64-bit OS with sv32 virtual addressing.

These patches will generate the .got, .got.plt and .plt sections during loading module, let it can refer to the symbol which locate more than 32-bit offset. These sections depend on the relocation types:
- R_RISCV_GOT_HI20
- R_RISCV_CALL_PLT

These patches also support more relocation types
- R_RISCV_CALL
- R_RISCV_HI20
- R_RISCV_LO12_I
- R_RISCV_LO12_S
- R_RISCV_RVC_BRANCH
- R_RISCV_RVC_JUMP
- R_RISCV_ALIGN
- R_RISCV_ADD32
- R_RISCV_SUB32

Zong Li (11):
RISC-V: Add sections of PLT and GOT for kernel module
RISC-V: Add section of GOT.PLT for kernel module
RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
RISC-V: Support CALL relocation type in kernel module
RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
RISC-V: Support ALIGN relocation type in kernel module
RISC-V: Support ADD32 relocation type in kernel module
RISC-V: Support SUB32 relocation type in kernel module
RISC-V: Enable module support in defconfig
RISC-V: Add definition of relocation types

Quoted 13 lines

 arch/riscv/Kconfig                  |   5 ++
 arch/riscv/Makefile                 |   3 +
 arch/riscv/configs/defconfig        |   2 +
 arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
 arch/riscv/include/uapi/asm/elf.h   |  24 +++++
 arch/riscv/kernel/Makefile          |   1 +
 arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
 arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
 arch/riscv/kernel/module.lds        |   8 ++
 9 files changed, 480 insertions(+), 6 deletions(-)
 create mode 100644 arch/riscv/include/asm/module.h
 create mode 100644 arch/riscv/kernel/module-sections.c
 create mode 100644 arch/riscv/kernel/module.lds

This is the second set of patches that turn on modules, and it has the same R_RISCV_ALIGN problem as the other one

    http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html

It looks like this one uses shared libraries for modules instead of static objects. I think using shared objects is the right thing to do, as it'll allow us to place modules anywhere in the address space by having multiple GOTs and PLTs.

That's kind of complicated, though, so we can start with something simpler like this.

Hi Palmer,

Quoted 60 lines · Palmer Dabbelt

Quoted 40 lines · zong at andestech.com

These patches resolve the some issues of loadable module.
- symbol out of ranges
- unknown relocation types

The reference of external variable and function symbols cannot exceed 32-bit offset ranges in kernel module. The module only can work on the 32-bit OS or the 64-bit OS with sv32 virtual addressing.

These patches will generate the .got, .got.plt and .plt sections during loading module, let it can refer to the symbol which locate more than 32-bit offset. These sections depend on the relocation types:
- R_RISCV_GOT_HI20
- R_RISCV_CALL_PLT

These patches also support more relocation types
- R_RISCV_CALL
- R_RISCV_HI20
- R_RISCV_LO12_I
- R_RISCV_LO12_S
- R_RISCV_RVC_BRANCH
- R_RISCV_RVC_JUMP
- R_RISCV_ALIGN
- R_RISCV_ADD32
- R_RISCV_SUB32

Zong Li (11):
RISC-V: Add sections of PLT and GOT for kernel module
RISC-V: Add section of GOT.PLT for kernel module
RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
RISC-V: Support CALL relocation type in kernel module
RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
RISC-V: Support ALIGN relocation type in kernel module
RISC-V: Support ADD32 relocation type in kernel module
RISC-V: Support SUB32 relocation type in kernel module
RISC-V: Enable module support in defconfig
RISC-V: Add definition of relocation types

Quoted 13 lines

 arch/riscv/Kconfig                  |   5 ++
 arch/riscv/Makefile                 |   3 +
 arch/riscv/configs/defconfig        |   2 +
 arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
 arch/riscv/include/uapi/asm/elf.h   |  24 +++++
 arch/riscv/kernel/Makefile          |   1 +
 arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
 arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
 arch/riscv/kernel/module.lds        |   8 ++
 9 files changed, 480 insertions(+), 6 deletions(-)
 create mode 100644 arch/riscv/include/asm/module.h
 create mode 100644 arch/riscv/kernel/module-sections.c
 create mode 100644 arch/riscv/kernel/module.lds

This is the second set of patches that turn on modules, and it has the same R_RISCV_ALIGN problem as the other one

    http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html

Quoted 4 lines

It looks like this one uses shared libraries for modules instead of static objects. I think using shared objects is the right thing to do, as it'll allow us to place modules anywhere in the address space by having multiple GOTs and PLTs.

Can you expand on this? It was my understanding that outside of the context of multiple address spaces sharing code the GOT and PLT were simply unnecessary overhead, what benefit would they bring here?

Quoted 2 lines

That's kind of complicated, though, so we can start with something simpler like this.

Quoted 2 lines

That's kind of complicated, though, so we can start with something simpler like this.

2018-03-14 5:30 GMT+08:00 Shea Levy <[email protected]>:

Quoted 64 lines

Hi Palmer,

Quoted 60 lines · Palmer Dabbelt

Quoted 40 lines · zong at andestech.com

These patches resolve the some issues of loadable module.
- symbol out of ranges
- unknown relocation types

The reference of external variable and function symbols cannot exceed 32-bit offset ranges in kernel module. The module only can work on the 32-bit OS or the 64-bit OS with sv32 virtual addressing.

These patches will generate the .got, .got.plt and .plt sections during loading module, let it can refer to the symbol which locate more than 32-bit offset. These sections depend on the relocation types:
- R_RISCV_GOT_HI20
- R_RISCV_CALL_PLT

These patches also support more relocation types
- R_RISCV_CALL
- R_RISCV_HI20
- R_RISCV_LO12_I
- R_RISCV_LO12_S
- R_RISCV_RVC_BRANCH
- R_RISCV_RVC_JUMP
- R_RISCV_ALIGN
- R_RISCV_ADD32
- R_RISCV_SUB32

Zong Li (11):
RISC-V: Add sections of PLT and GOT for kernel module
RISC-V: Add section of GOT.PLT for kernel module
RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
RISC-V: Support CALL relocation type in kernel module
RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
RISC-V: Support ALIGN relocation type in kernel module
RISC-V: Support ADD32 relocation type in kernel module
RISC-V: Support SUB32 relocation type in kernel module
RISC-V: Enable module support in defconfig
RISC-V: Add definition of relocation types

Quoted 13 lines

 arch/riscv/Kconfig                  |   5 ++
 arch/riscv/Makefile                 |   3 +
 arch/riscv/configs/defconfig        |   2 +
 arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
 arch/riscv/include/uapi/asm/elf.h   |  24 +++++
 arch/riscv/kernel/Makefile          |   1 +
 arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
 arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
 arch/riscv/kernel/module.lds        |   8 ++
 9 files changed, 480 insertions(+), 6 deletions(-)
 create mode 100644 arch/riscv/include/asm/module.h
 create mode 100644 arch/riscv/kernel/module-sections.c
 create mode 100644 arch/riscv/kernel/module.lds

This is the second set of patches that turn on modules, and it has the same R_RISCV_ALIGN problem as the other one

    http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html

Quoted 11 lines

Quoted 4 lines

It looks like this one uses shared libraries for modules instead of static objects. I think using shared objects is the right thing to do, as it'll allow us to place modules anywhere in the address space by having multiple GOTs and PLTs.

Can you expand on this? It was my understanding that outside of the context of multiple address spaces sharing code the GOT and PLT were simply unnecessary overhead, what benefit would they bring here?

Quoted 2 lines

That's kind of complicated, though, so we can start with something simpler like this.

Hi,

The kernel module is a object file, it is not be linked by linker, the GOT and PLT
sections will not be generated through -fPIC option, but it will generate the relative
relocation type. As Palmer mention before, If we have GOT and PLT sections, we can put the module anywhere, even we support the KASLR in the kernel.

For the ALIGN problem, the kernel module loader is difficult to remove or migrate
the module's code like relax doing, so the remnant nop instructions harm the performance, I agree the point that adding the mno-relax option and checking the alignment in ALIGN type in module loader.

Quoted 2 lines

Quoted 2 lines

That's kind of complicated, though, so we can start with something simpler like this.

So what is the suggestion for that.

Hi Palmer,

Quoted 60 lines · Palmer Dabbelt

Quoted 40 lines · zong at andestech.com

These patches resolve the some issues of loadable module.
- symbol out of ranges
- unknown relocation types

The reference of external variable and function symbols cannot exceed 32-bit offset ranges in kernel module. The module only can work on the 32-bit OS or the 64-bit OS with sv32 virtual addressing.

These patches will generate the .got, .got.plt and .plt sections during loading module, let it can refer to the symbol which locate more than 32-bit offset. These sections depend on the relocation types:
- R_RISCV_GOT_HI20
- R_RISCV_CALL_PLT

These patches also support more relocation types
- R_RISCV_CALL
- R_RISCV_HI20
- R_RISCV_LO12_I
- R_RISCV_LO12_S
- R_RISCV_RVC_BRANCH
- R_RISCV_RVC_JUMP
- R_RISCV_ALIGN
- R_RISCV_ADD32
- R_RISCV_SUB32

Zong Li (11):
RISC-V: Add sections of PLT and GOT for kernel module
RISC-V: Add section of GOT.PLT for kernel module
RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
RISC-V: Support CALL relocation type in kernel module
RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
RISC-V: Support ALIGN relocation type in kernel module
RISC-V: Support ADD32 relocation type in kernel module
RISC-V: Support SUB32 relocation type in kernel module
RISC-V: Enable module support in defconfig
RISC-V: Add definition of relocation types

Quoted 13 lines

 arch/riscv/Kconfig                  |   5 ++
 arch/riscv/Makefile                 |   3 +
 arch/riscv/configs/defconfig        |   2 +
 arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
 arch/riscv/include/uapi/asm/elf.h   |  24 +++++
 arch/riscv/kernel/Makefile          |   1 +
 arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
 arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
 arch/riscv/kernel/module.lds        |   8 ++
 9 files changed, 480 insertions(+), 6 deletions(-)
 create mode 100644 arch/riscv/include/asm/module.h
 create mode 100644 arch/riscv/kernel/module-sections.c
 create mode 100644 arch/riscv/kernel/module.lds

This is the second set of patches that turn on modules, and it has the same R_RISCV_ALIGN problem as the other one

    http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html

Quoted 4 lines

It looks like this one uses shared libraries for modules instead of static objects. I think using shared objects is the right thing to do, as it'll allow us to place modules anywhere in the address space by having multiple GOTs and PLTs.

Can you expand on this? It was my understanding that outside of the context of multiple address spaces sharing code the GOT and PLT were simply unnecessary overhead, what benefit would they bring here?

Quoted 92 lines

2018-03-14 5:30 GMT+08:00 Shea Levy <[email protected]>:

Quoted 80 lines

Hi Palmer,

Quoted 66 lines · Palmer Dabbelt

Quoted 41 lines · zong at andestech.com

These patches resolve the some issues of loadable module.
- symbol out of ranges
- unknown relocation types

The reference of external variable and function symbols cannot exceed 32-bit offset ranges in kernel module. The module only can work on the 32-bit OS or the 64-bit OS with sv32 virtual addressing.

These patches will generate the .got, .got.plt and .plt sections during loading module, let it can refer to the symbol which locate more than 32-bit offset. These sections depend on the relocation types:
- R_RISCV_GOT_HI20
- R_RISCV_CALL_PLT

These patches also support more relocation types
- R_RISCV_CALL
- R_RISCV_HI20
- R_RISCV_LO12_I
- R_RISCV_LO12_S
- R_RISCV_RVC_BRANCH
- R_RISCV_RVC_JUMP
- R_RISCV_ALIGN
- R_RISCV_ADD32
- R_RISCV_SUB32

Zong Li (11):
RISC-V: Add sections of PLT and GOT for kernel module
RISC-V: Add section of GOT.PLT for kernel module
RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
RISC-V: Support CALL relocation type in kernel module
RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
RISC-V: Support ALIGN relocation type in kernel module
RISC-V: Support ADD32 relocation type in kernel module
RISC-V: Support SUB32 relocation type in kernel module
RISC-V: Enable module support in defconfig
RISC-V: Add definition of relocation types

Quoted 15 lines

 arch/riscv/Kconfig                  |   5 ++
 arch/riscv/Makefile                 |   3 +
 arch/riscv/configs/defconfig        |   2 +
 arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
 arch/riscv/include/uapi/asm/elf.h   |  24 +++++
 arch/riscv/kernel/Makefile          |   1 +
 arch/riscv/kernel/module-sections.c | 156
++++++++++++++++++++++++++++++++
 arch/riscv/kernel/module.c          | 175
++++++++++++++++++++++++++++++++++--
 arch/riscv/kernel/module.lds        |   8 ++
 9 files changed, 480 insertions(+), 6 deletions(-)
 create mode 100644 arch/riscv/include/asm/module.h
 create mode 100644 arch/riscv/kernel/module-sections.c
 create mode 100644 arch/riscv/kernel/module.lds

This is the second set of patches that turn on modules, and it has the same
R_RISCV_ALIGN problem as the other one

http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html

Quoted 7 lines

It looks like this one uses shared libraries for modules instead of static
objects. I think using shared objects is the right thing to do, as it'll allow
us to place modules anywhere in the address space by having multiple GOTs and
PLTs.

Quoted 6 lines

Can you expand on this? It was my understanding that outside of the context of multiple address spaces sharing code the GOT and PLT were simply unnecessary overhead, what benefit would they bring here?

Quoted 2 lines

That's kind of complicated, though, so we can start with something simpler like this.

Hi,

Quoted 7 lines

The kernel module is a object file, it is not be linked by linker, the GOT and PLT
sections will not be generated through -fPIC option, but it will generate the relative
relocation type. As Palmer mention before, If we have GOT and PLT sections,
we can put the module anywhere, even we support the KASLR in the kernel.

Sorry, I guess I meant PIC objects not shared objects (I keep forgetting about
PIE). We'll probably eventually add large code model targets, but they might
end up just being functionally equilivant to PIE with multi-GOT and multi-PLT
so it might not matter.

Either way, this is the sanest way to do it for now.

Quoted 7 lines

For the ALIGN problem, the kernel module loader is difficult to remove or migrate
the module's code like relax doing, so the remnant nop instructions harm the
performance, I agree the point that adding the mno-relax option and checking
the alignment in ALIGN type in module loader.

Sounds good. I just merged the mno-relax stuff, it'll show up when I get around to generating a 7.3.0 backport branch. For now I think you should just
fail on R_RISCV_ALIGN and attempt to pass -mno-relax to the compiler (via something like "$(call cc-option,-mno-relax)", like we do for "-mstrict-align"). I don't think it's worth handling R_RISCV_ALIGN in the kernel, as that's essentially the same as full relaxation support.

If I understand your code correctly, you're currently generating one GOT and one PLT per loaded module. If that's the case, then this is correct, it's just
possible to save some memory by merging these tables. It's probably not worth
the complexity for kernel modules for a while.

Quoted 77 lines · zongbox at gmail.com

2018-03-14 5:30 GMT+08:00 Shea Levy <[email protected]>:

Quoted 64 lines

Hi Palmer,

Quoted 60 lines · Palmer Dabbelt

Quoted 40 lines · zong at andestech.com

These patches resolve the some issues of loadable module.
- symbol out of ranges
- unknown relocation types

The reference of external variable and function symbols cannot exceed 32-bit offset ranges in kernel module. The module only can work on the 32-bit OS or the 64-bit OS with sv32 virtual addressing.

These patches will generate the .got, .got.plt and .plt sections during loading module, let it can refer to the symbol which locate more than 32-bit offset. These sections depend on the relocation types:
- R_RISCV_GOT_HI20
- R_RISCV_CALL_PLT

These patches also support more relocation types
- R_RISCV_CALL
- R_RISCV_HI20
- R_RISCV_LO12_I
- R_RISCV_LO12_S
- R_RISCV_RVC_BRANCH
- R_RISCV_RVC_JUMP
- R_RISCV_ALIGN
- R_RISCV_ADD32
- R_RISCV_SUB32

Zong Li (11):
RISC-V: Add sections of PLT and GOT for kernel module
RISC-V: Add section of GOT.PLT for kernel module
RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
RISC-V: Support CALL relocation type in kernel module
RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
RISC-V: Support ALIGN relocation type in kernel module
RISC-V: Support ADD32 relocation type in kernel module
RISC-V: Support SUB32 relocation type in kernel module
RISC-V: Enable module support in defconfig
RISC-V: Add definition of relocation types

Quoted 13 lines

 arch/riscv/Kconfig                  |   5 ++
 arch/riscv/Makefile                 |   3 +
 arch/riscv/configs/defconfig        |   2 +
 arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
 arch/riscv/include/uapi/asm/elf.h   |  24 +++++
 arch/riscv/kernel/Makefile          |   1 +
 arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
 arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
 arch/riscv/kernel/module.lds        |   8 ++
 9 files changed, 480 insertions(+), 6 deletions(-)
 create mode 100644 arch/riscv/include/asm/module.h
 create mode 100644 arch/riscv/kernel/module-sections.c
 create mode 100644 arch/riscv/kernel/module.lds

This is the second set of patches that turn on modules, and it has the same R_RISCV_ALIGN problem as the other one

    http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html

Quoted 11 lines

Quoted 4 lines

It looks like this one uses shared libraries for modules instead of static objects. I think using shared objects is the right thing to do, as it'll allow us to place modules anywhere in the address space by having multiple GOTs and PLTs.

Can you expand on this? It was my understanding that outside of the context of multiple address spaces sharing code the GOT and PLT were simply unnecessary overhead, what benefit would they bring here?

Quoted 2 lines

That's kind of complicated, though, so we can start with something simpler like this.

Quoted 8 lines

Hi,

The kernel module is a object file, it is not be linked by linker, the GOT and PLT
sections will not be generated through -fPIC option, but it will generate the relative
relocation type. As Palmer mention before, If we have GOT and PLT sections, we can put the module anywhere, even we support the KASLR in the kernel.

Sorry, I guess I meant PIC objects not shared objects (I keep forgetting about PIE). We'll probably eventually add large code model targets, but they might end up just being functionally equilivant to PIE with multi-GOT and multi-PLT so it might not matter.

Either way, this is the sanest way to do it for now.

Quoted 5 lines

For the ALIGN problem, the kernel module loader is difficult to remove or migrate
the module's code like relax doing, so the remnant nop instructions harm the performance, I agree the point that adding the mno-relax option and checking the alignment in ALIGN type in module loader.

Sounds good. I just merged the mno-relax stuff, it'll show up when I get around to generating a 7.3.0 backport branch. For now I think you should just fail on R_RISCV_ALIGN and attempt to pass -mno-relax to the compiler (via something like "$(call cc-option,-mno-relax)", like we do for "-mstrict-align"). I don't think it's worth handling R_RISCV_ALIGN in the kernel, as that's essentially the same as full relaxation support.

Quoted 5 lines

Quoted 3 lines

Quoted 3 lines

That's kind of complicated, though, so we can start with something simpler like this.

So what is the suggestion for that.

Well, I'm not really sure -- essentially the idea of proper multi-GOT and multi-PLT support would be to merge the GOTs and PLTs of modules together when they're within range of each other. We haven't even figured this out in userspace yet, so it's probably not worth attempting for kernel modules for a bit.

If I understand your code correctly, you're currently generating one GOT and one PLT per loaded module. If that's the case, then this is correct, it's just possible to save some memory by merging these tables. It's probably not worth the complexity for kernel modules for a while.

2018-03-14 11:07 GMT+08:00 Palmer Dabbelt <[email protected]>:

Quoted 110 lines · zongbox at gmail.com

Quoted 92 lines

2018-03-14 5:30 GMT+08:00 Shea Levy <[email protected]>:

Quoted 80 lines

Hi Palmer,

Quoted 66 lines · Palmer Dabbelt

Quoted 41 lines · zong at andestech.com

These patches resolve the some issues of loadable module.
- symbol out of ranges
- unknown relocation types

The reference of external variable and function symbols cannot exceed 32-bit offset ranges in kernel module. The module only can work on the 32-bit OS or the 64-bit OS with sv32 virtual addressing.

These patches will generate the .got, .got.plt and .plt sections during loading module, let it can refer to the symbol which locate more than 32-bit offset. These sections depend on the relocation types:
- R_RISCV_GOT_HI20
- R_RISCV_CALL_PLT

These patches also support more relocation types
- R_RISCV_CALL
- R_RISCV_HI20
- R_RISCV_LO12_I
- R_RISCV_LO12_S
- R_RISCV_RVC_BRANCH
- R_RISCV_RVC_JUMP
- R_RISCV_ALIGN
- R_RISCV_ADD32
- R_RISCV_SUB32

Zong Li (11):
RISC-V: Add sections of PLT and GOT for kernel module
RISC-V: Add section of GOT.PLT for kernel module
RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
RISC-V: Support CALL relocation type in kernel module
RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
RISC-V: Support ALIGN relocation type in kernel module
RISC-V: Support ADD32 relocation type in kernel module
RISC-V: Support SUB32 relocation type in kernel module
RISC-V: Enable module support in defconfig
RISC-V: Add definition of relocation types

Quoted 15 lines

 arch/riscv/Kconfig                  |   5 ++
 arch/riscv/Makefile                 |   3 +
 arch/riscv/configs/defconfig        |   2 +
 arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
 arch/riscv/include/uapi/asm/elf.h   |  24 +++++
 arch/riscv/kernel/Makefile          |   1 +
 arch/riscv/kernel/module-sections.c | 156
++++++++++++++++++++++++++++++++
 arch/riscv/kernel/module.c          | 175
++++++++++++++++++++++++++++++++++--
 arch/riscv/kernel/module.lds        |   8 ++
 9 files changed, 480 insertions(+), 6 deletions(-)
 create mode 100644 arch/riscv/include/asm/module.h
 create mode 100644 arch/riscv/kernel/module-sections.c
 create mode 100644 arch/riscv/kernel/module.lds

This is the second set of patches that turn on modules, and it has the same
R_RISCV_ALIGN problem as the other one

http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html

Quoted 7 lines

It looks like this one uses shared libraries for modules instead of static
objects. I think using shared objects is the right thing to do, as it'll allow
us to place modules anywhere in the address space by having multiple GOTs and
PLTs.

Quoted 6 lines

Can you expand on this? It was my understanding that outside of the context of multiple address spaces sharing code the GOT and PLT were simply unnecessary overhead, what benefit would they bring here?

Quoted 2 lines

That's kind of complicated, though, so we can start with something simpler like this.

Hi,

Quoted 7 lines

The kernel module is a object file, it is not be linked by linker, the GOT and PLT
sections will not be generated through -fPIC option, but it will generate the relative
relocation type. As Palmer mention before, If we have GOT and PLT sections,
we can put the module anywhere, even we support the KASLR in the kernel.

Sorry, I guess I meant PIC objects not shared objects (I keep forgetting about
PIE). We'll probably eventually add large code model targets, but they might
end up just being functionally equilivant to PIE with multi-GOT and multi-PLT
so it might not matter.

Quoted 1 line

Either way, this is the sanest way to do it for now.

Actually, I try to use the large code model and without PIC before. (The compiler with mcmodel=large obtain from my colleague development) On this compiler version, the -mcmodel=large uses the constant pool mechanism to
puts the addresses of data symbols at the function tail. It can resolve the reference about out of range of data symbol, but this code generation not apply to function call. For the compiler code generation and no linker to do relax reason, kernel module still needs the PLT section to jump to far target. On the other hand, the ARM64 mailing list has the patches to remove the large code model for cache performance.

https://marc.info/?l=linux-arm-kernel&m=151860828416766

so maybe we can use the medany + fPIC for now.

Quoted 9 lines

Quoted 7 lines

For the ALIGN problem, the kernel module loader is difficult to remove or migrate
the module's code like relax doing, so the remnant nop instructions harm the
performance, I agree the point that adding the mno-relax option and checking
the alignment in ALIGN type in module loader.

Quoted 7 lines

Sounds good. I just merged the mno-relax stuff, it'll show up when I get around to generating a 7.3.0 backport branch. For now I think you should just
fail on R_RISCV_ALIGN and attempt to pass -mno-relax to the compiler (via something like "$(call cc-option,-mno-relax)", like we do for "-mstrict-align"). I don't think it's worth handling R_RISCV_ALIGN in the kernel, as that's essentially the same as full relaxation support.

OK. I will send the v2 patches with the modification as you mention about R_RISCV_ALIGN type?

Quoted 7 lines

If I understand your code correctly, you're currently generating one GOT and one PLT per loaded module. If that's the case, then this is correct, it's just
possible to save some memory by merging these tables. It's probably not worth
the complexity for kernel modules for a while.

Yes, there are one GOT and one PLT per loaded module.
In the [PATCH 02/11], I generate the third section .got.plt for saving more memory of
each PLT entry.

Thanks a lot.

Quoted 64 lines · shea at shealevy.com

Hi Palmer,

Quoted 60 lines · Palmer Dabbelt

Quoted 40 lines · zong at andestech.com

These patches resolve the some issues of loadable module.
- symbol out of ranges
- unknown relocation types

The reference of external variable and function symbols cannot exceed 32-bit offset ranges in kernel module. The module only can work on the 32-bit OS or the 64-bit OS with sv32 virtual addressing.

These patches will generate the .got, .got.plt and .plt sections during loading module, let it can refer to the symbol which locate more than 32-bit offset. These sections depend on the relocation types:
- R_RISCV_GOT_HI20
- R_RISCV_CALL_PLT

These patches also support more relocation types
- R_RISCV_CALL
- R_RISCV_HI20
- R_RISCV_LO12_I
- R_RISCV_LO12_S
- R_RISCV_RVC_BRANCH
- R_RISCV_RVC_JUMP
- R_RISCV_ALIGN
- R_RISCV_ADD32
- R_RISCV_SUB32

Zong Li (11):
RISC-V: Add sections of PLT and GOT for kernel module
RISC-V: Add section of GOT.PLT for kernel module
RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
RISC-V: Support CALL relocation type in kernel module
RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
RISC-V: Support ALIGN relocation type in kernel module
RISC-V: Support ADD32 relocation type in kernel module
RISC-V: Support SUB32 relocation type in kernel module
RISC-V: Enable module support in defconfig
RISC-V: Add definition of relocation types

Quoted 13 lines

 arch/riscv/Kconfig                  |   5 ++
 arch/riscv/Makefile                 |   3 +
 arch/riscv/configs/defconfig        |   2 +
 arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
 arch/riscv/include/uapi/asm/elf.h   |  24 +++++
 arch/riscv/kernel/Makefile          |   1 +
 arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
 arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
 arch/riscv/kernel/module.lds        |   8 ++
 9 files changed, 480 insertions(+), 6 deletions(-)
 create mode 100644 arch/riscv/include/asm/module.h
 create mode 100644 arch/riscv/kernel/module-sections.c
 create mode 100644 arch/riscv/kernel/module.lds

This is the second set of patches that turn on modules, and it has the same R_RISCV_ALIGN problem as the other one

    http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html

Quoted 8 lines

Quoted 4 lines

It looks like this one uses shared libraries for modules instead of static objects. I think using shared objects is the right thing to do, as it'll allow us to place modules anywhere in the address space by having multiple GOTs and PLTs.

Can you expand on this? It was my understanding that outside of the context of multiple address spaces sharing code the GOT and PLT were simply unnecessary overhead, what benefit would they bring here?

We don't currently have any position-dependent RISC-V code models larger than "medany", in which all code and data must live within a single 32-bit addressable range. The PLT and GOT sort of provide an out here, so the code only needs to get to the table (which can then get anywhere via an indirection layer).

This is relevant for Linux modules because it lets us load modules anywhere in the address space. It's also a bit of a headache, as it either requires a GOT+PLT per module (which is big) or merging tables (which is hard).

Quoted 145 lines · Zong Li

2018-03-14 11:07 GMT+08:00 Palmer Dabbelt <[email protected]>:

Quoted 110 lines · zongbox at gmail.com

Quoted 92 lines

2018-03-14 5:30 GMT+08:00 Shea Levy <[email protected]>:

Quoted 80 lines

Hi Palmer,

Quoted 66 lines · Palmer Dabbelt

Quoted 41 lines · zong at andestech.com

These patches resolve the some issues of loadable module.
- symbol out of ranges
- unknown relocation types

The reference of external variable and function symbols cannot exceed 32-bit offset ranges in kernel module. The module only can work on the 32-bit OS or the 64-bit OS with sv32 virtual addressing.

These patches will generate the .got, .got.plt and .plt sections during loading module, let it can refer to the symbol which locate more than 32-bit offset. These sections depend on the relocation types:
- R_RISCV_GOT_HI20
- R_RISCV_CALL_PLT

These patches also support more relocation types
- R_RISCV_CALL
- R_RISCV_HI20
- R_RISCV_LO12_I
- R_RISCV_LO12_S
- R_RISCV_RVC_BRANCH
- R_RISCV_RVC_JUMP
- R_RISCV_ALIGN
- R_RISCV_ADD32
- R_RISCV_SUB32

Zong Li (11):
RISC-V: Add sections of PLT and GOT for kernel module
RISC-V: Add section of GOT.PLT for kernel module
RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
RISC-V: Support CALL relocation type in kernel module
RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
RISC-V: Support ALIGN relocation type in kernel module
RISC-V: Support ADD32 relocation type in kernel module
RISC-V: Support SUB32 relocation type in kernel module
RISC-V: Enable module support in defconfig
RISC-V: Add definition of relocation types

Quoted 15 lines

 arch/riscv/Kconfig                  |   5 ++
 arch/riscv/Makefile                 |   3 +
 arch/riscv/configs/defconfig        |   2 +
 arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
 arch/riscv/include/uapi/asm/elf.h   |  24 +++++
 arch/riscv/kernel/Makefile          |   1 +
 arch/riscv/kernel/module-sections.c | 156
++++++++++++++++++++++++++++++++
 arch/riscv/kernel/module.c          | 175
++++++++++++++++++++++++++++++++++--
 arch/riscv/kernel/module.lds        |   8 ++
 9 files changed, 480 insertions(+), 6 deletions(-)
 create mode 100644 arch/riscv/include/asm/module.h
 create mode 100644 arch/riscv/kernel/module-sections.c
 create mode 100644 arch/riscv/kernel/module.lds

This is the second set of patches that turn on modules, and it has the same
R_RISCV_ALIGN problem as the other one

http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html

Quoted 7 lines

It looks like this one uses shared libraries for modules instead of static
objects. I think using shared objects is the right thing to do, as it'll allow
us to place modules anywhere in the address space by having multiple GOTs and
PLTs.

Quoted 6 lines

Can you expand on this? It was my understanding that outside of the context of multiple address spaces sharing code the GOT and PLT were simply unnecessary overhead, what benefit would they bring here?

Quoted 2 lines

That's kind of complicated, though, so we can start with something simpler like this.

Hi,

Quoted 7 lines

The kernel module is a object file, it is not be linked by linker, the GOT and PLT
sections will not be generated through -fPIC option, but it will generate the relative
relocation type. As Palmer mention before, If we have GOT and PLT sections,
we can put the module anywhere, even we support the KASLR in the kernel.

Sorry, I guess I meant PIC objects not shared objects (I keep forgetting about
PIE). We'll probably eventually add large code model targets, but they might
end up just being functionally equilivant to PIE with multi-GOT and multi-PLT
so it might not matter.

Quoted 1 line

Either way, this is the sanest way to do it for now.

Actually, I try to use the large code model and without PIC before. (The compiler with mcmodel=large obtain from my colleague development) On this compiler version, the -mcmodel=large uses the constant pool mechanism to
puts the addresses of data symbols at the function tail. It can resolve the reference about out of range of data symbol, but this code generation not apply to function call. For the compiler code generation and no linker to do relax reason, kernel module still needs the PLT section to jump to far target. On the other hand, the ARM64 mailing list has the patches to remove the large code model for cache performance.

https://marc.info/?l=linux-arm-kernel&m=151860828416766

so maybe we can use the medany + fPIC for now.

Quoted 16 lines

Quoted 7 lines

For the ALIGN problem, the kernel module loader is difficult to remove or migrate
the module's code like relax doing, so the remnant nop instructions harm the
performance, I agree the point that adding the mno-relax option and checking
the alignment in ALIGN type in module loader.

Sounds good. I just merged the mno-relax stuff, it'll show up when I get around to generating a 7.3.0 backport branch. For now I think you should just
fail on R_RISCV_ALIGN and attempt to pass -mno-relax to the compiler (via something like "$(call cc-option,-mno-relax)", like we do for "-mstrict-align"). I don't think it's worth handling R_RISCV_ALIGN in the kernel, as that's essentially the same as full relaxation support.

Quoted 2 lines

OK. I will send the v2 patches with the modification as you mention about R_RISCV_ALIGN type?

Just to avoid work duplication, do you think you'll get to this before this weekend? I was planning on bringing my patches up-to-date then, but since we're going the PIC route I can base my no-relax/ALIGN support on top of your series instead.

Quoted 14 lines

Quoted 7 lines

If I understand your code correctly, you're currently generating one GOT and one PLT per loaded module. If that's the case, then this is correct, it's just
possible to save some memory by merging these tables. It's probably not worth
the complexity for kernel modules for a while.

Yes, there are one GOT and one PLT per loaded module.
In the [PATCH 02/11], I generate the third section .got.plt for saving more memory of
each PLT entry.

Thanks a lot.

Quoted 100 lines · Palmer Dabbelt

Quoted 77 lines · zongbox at gmail.com

2018-03-14 5:30 GMT+08:00 Shea Levy <[email protected]>:

Quoted 64 lines

Hi Palmer,

Quoted 60 lines · Palmer Dabbelt

Quoted 40 lines · zong at andestech.com

These patches resolve the some issues of loadable module.
- symbol out of ranges
- unknown relocation types

The reference of external variable and function symbols cannot exceed 32-bit offset ranges in kernel module. The module only can work on the 32-bit OS or the 64-bit OS with sv32 virtual addressing.

These patches will generate the .got, .got.plt and .plt sections during loading module, let it can refer to the symbol which locate more than 32-bit offset. These sections depend on the relocation types:
- R_RISCV_GOT_HI20
- R_RISCV_CALL_PLT

These patches also support more relocation types
- R_RISCV_CALL
- R_RISCV_HI20
- R_RISCV_LO12_I
- R_RISCV_LO12_S
- R_RISCV_RVC_BRANCH
- R_RISCV_RVC_JUMP
- R_RISCV_ALIGN
- R_RISCV_ADD32
- R_RISCV_SUB32

Zong Li (11):
RISC-V: Add sections of PLT and GOT for kernel module
RISC-V: Add section of GOT.PLT for kernel module
RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
RISC-V: Support CALL relocation type in kernel module
RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
RISC-V: Support ALIGN relocation type in kernel module
RISC-V: Support ADD32 relocation type in kernel module
RISC-V: Support SUB32 relocation type in kernel module
RISC-V: Enable module support in defconfig
RISC-V: Add definition of relocation types

Quoted 13 lines

 arch/riscv/Kconfig                  |   5 ++
 arch/riscv/Makefile                 |   3 +
 arch/riscv/configs/defconfig        |   2 +
 arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
 arch/riscv/include/uapi/asm/elf.h   |  24 +++++
 arch/riscv/kernel/Makefile          |   1 +
 arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
 arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
 arch/riscv/kernel/module.lds        |   8 ++
 9 files changed, 480 insertions(+), 6 deletions(-)
 create mode 100644 arch/riscv/include/asm/module.h
 create mode 100644 arch/riscv/kernel/module-sections.c
 create mode 100644 arch/riscv/kernel/module.lds

This is the second set of patches that turn on modules, and it has the same R_RISCV_ALIGN problem as the other one

    http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html

Quoted 11 lines

Quoted 4 lines

It looks like this one uses shared libraries for modules instead of static objects. I think using shared objects is the right thing to do, as it'll allow us to place modules anywhere in the address space by having multiple GOTs and PLTs.

Can you expand on this? It was my understanding that outside of the context of multiple address spaces sharing code the GOT and PLT were simply unnecessary overhead, what benefit would they bring here?

Quoted 2 lines

That's kind of complicated, though, so we can start with something simpler like this.

Quoted 8 lines

Hi,

The kernel module is a object file, it is not be linked by linker, the GOT and PLT
sections will not be generated through -fPIC option, but it will generate the relative
relocation type. As Palmer mention before, If we have GOT and PLT sections, we can put the module anywhere, even we support the KASLR in the kernel.

Sorry, I guess I meant PIC objects not shared objects (I keep forgetting about PIE). We'll probably eventually add large code model targets, but they might end up just being functionally equilivant to PIE with multi-GOT and multi-PLT so it might not matter.

Either way, this is the sanest way to do it for now.

Quoted 5 lines

For the ALIGN problem, the kernel module loader is difficult to remove or migrate
the module's code like relax doing, so the remnant nop instructions harm the performance, I agree the point that adding the mno-relax option and checking the alignment in ALIGN type in module loader.

Quoted 7 lines

Sounds good. I just merged the mno-relax stuff, it'll show up when I get around to generating a 7.3.0 backport branch. For now I think you should just fail on R_RISCV_ALIGN and attempt to pass -mno-relax to the compiler (via something like "$(call cc-option,-mno-relax)", like we do for "-mstrict-align"). I don't think it's worth handling R_RISCV_ALIGN in the kernel, as that's essentially the same as full relaxation support.

Should we unconditionally fail on R_RISCV_ALIGN or only if the code isn't already aligned?

Quoted 16 lines

Quoted 5 lines

Quoted 3 lines

Quoted 3 lines

That's kind of complicated, though, so we can start with something simpler like this.

So what is the suggestion for that.

Well, I'm not really sure -- essentially the idea of proper multi-GOT and multi-PLT support would be to merge the GOTs and PLTs of modules together when they're within range of each other. We haven't even figured this out in userspace yet, so it's probably not worth attempting for kernel modules for a bit.

If I understand your code correctly, you're currently generating one GOT and one PLT per loaded module. If that's the case, then this is correct, it's just possible to save some memory by merging these tables. It's probably not worth the complexity for kernel modules for a while.

Quoted 80 lines · Palmer Dabbelt

Quoted 64 lines · shea at shealevy.com

Hi Palmer,

Quoted 60 lines · Palmer Dabbelt

Quoted 40 lines · zong at andestech.com

These patches resolve the some issues of loadable module.
- symbol out of ranges
- unknown relocation types

The reference of external variable and function symbols cannot exceed 32-bit offset ranges in kernel module. The module only can work on the 32-bit OS or the 64-bit OS with sv32 virtual addressing.

These patches will generate the .got, .got.plt and .plt sections during loading module, let it can refer to the symbol which locate more than 32-bit offset. These sections depend on the relocation types:
- R_RISCV_GOT_HI20
- R_RISCV_CALL_PLT

These patches also support more relocation types
- R_RISCV_CALL
- R_RISCV_HI20
- R_RISCV_LO12_I
- R_RISCV_LO12_S
- R_RISCV_RVC_BRANCH
- R_RISCV_RVC_JUMP
- R_RISCV_ALIGN
- R_RISCV_ADD32
- R_RISCV_SUB32

Zong Li (11):
RISC-V: Add sections of PLT and GOT for kernel module
RISC-V: Add section of GOT.PLT for kernel module
RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
RISC-V: Support CALL relocation type in kernel module
RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
RISC-V: Support ALIGN relocation type in kernel module
RISC-V: Support ADD32 relocation type in kernel module
RISC-V: Support SUB32 relocation type in kernel module
RISC-V: Enable module support in defconfig
RISC-V: Add definition of relocation types

Quoted 13 lines

 arch/riscv/Kconfig                  |   5 ++
 arch/riscv/Makefile                 |   3 +
 arch/riscv/configs/defconfig        |   2 +
 arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
 arch/riscv/include/uapi/asm/elf.h   |  24 +++++
 arch/riscv/kernel/Makefile          |   1 +
 arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
 arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
 arch/riscv/kernel/module.lds        |   8 ++
 9 files changed, 480 insertions(+), 6 deletions(-)
 create mode 100644 arch/riscv/include/asm/module.h
 create mode 100644 arch/riscv/kernel/module-sections.c
 create mode 100644 arch/riscv/kernel/module.lds

This is the second set of patches that turn on modules, and it has the same R_RISCV_ALIGN problem as the other one

    http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html

Quoted 8 lines

Quoted 4 lines

It looks like this one uses shared libraries for modules instead of static objects. I think using shared objects is the right thing to do, as it'll allow us to place modules anywhere in the address space by having multiple GOTs and PLTs.

Can you expand on this? It was my understanding that outside of the context of multiple address spaces sharing code the GOT and PLT were simply unnecessary overhead, what benefit would they bring here?

We don't currently have any position-dependent RISC-V code models larger than "medany", in which all code and data must live within a single 32-bit addressable range. The PLT and GOT sort of provide an out here, so the code only needs to get to the table (which can then get anywhere via an indirection layer).

Quoted 3 lines

This is relevant for Linux modules because it lets us load modules anywhere in the address space. It's also a bit of a headache, as it either requires a GOT+PLT per module (which is big) or merging tables (which is hard).

I see, thanks! We only get this benefit if we actually do the relevanat indirection in the table, right? And if we merge tables we still have to have all modules within 32 bits of the common table? Is this how some future "medlarge" code model will work, or is it more of a convenient way to reuse existing techniques until other code models are worked out?

Quoted 86 lines · shea at shealevy.com

Quoted 80 lines · Palmer Dabbelt

Quoted 64 lines · shea at shealevy.com

Hi Palmer,

Quoted 60 lines · Palmer Dabbelt

Quoted 40 lines · zong at andestech.com

These patches resolve the some issues of loadable module.
- symbol out of ranges
- unknown relocation types

The reference of external variable and function symbols cannot exceed 32-bit offset ranges in kernel module. The module only can work on the 32-bit OS or the 64-bit OS with sv32 virtual addressing.

These patches will generate the .got, .got.plt and .plt sections during loading module, let it can refer to the symbol which locate more than 32-bit offset. These sections depend on the relocation types:
- R_RISCV_GOT_HI20
- R_RISCV_CALL_PLT

These patches also support more relocation types
- R_RISCV_CALL
- R_RISCV_HI20
- R_RISCV_LO12_I
- R_RISCV_LO12_S
- R_RISCV_RVC_BRANCH
- R_RISCV_RVC_JUMP
- R_RISCV_ALIGN
- R_RISCV_ADD32
- R_RISCV_SUB32

Zong Li (11):
RISC-V: Add sections of PLT and GOT for kernel module
RISC-V: Add section of GOT.PLT for kernel module
RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
RISC-V: Support CALL relocation type in kernel module
RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
RISC-V: Support ALIGN relocation type in kernel module
RISC-V: Support ADD32 relocation type in kernel module
RISC-V: Support SUB32 relocation type in kernel module
RISC-V: Enable module support in defconfig
RISC-V: Add definition of relocation types

Quoted 13 lines

 arch/riscv/Kconfig                  |   5 ++
 arch/riscv/Makefile                 |   3 +
 arch/riscv/configs/defconfig        |   2 +
 arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
 arch/riscv/include/uapi/asm/elf.h   |  24 +++++
 arch/riscv/kernel/Makefile          |   1 +
 arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
 arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
 arch/riscv/kernel/module.lds        |   8 ++
 9 files changed, 480 insertions(+), 6 deletions(-)
 create mode 100644 arch/riscv/include/asm/module.h
 create mode 100644 arch/riscv/kernel/module-sections.c
 create mode 100644 arch/riscv/kernel/module.lds

This is the second set of patches that turn on modules, and it has the same R_RISCV_ALIGN problem as the other one

    http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html

Quoted 8 lines

Quoted 4 lines

It looks like this one uses shared libraries for modules instead of static objects. I think using shared objects is the right thing to do, as it'll allow us to place modules anywhere in the address space by having multiple GOTs and PLTs.

Can you expand on this? It was my understanding that outside of the context of multiple address spaces sharing code the GOT and PLT were simply unnecessary overhead, what benefit would they bring here?

We don't currently have any position-dependent RISC-V code models larger than "medany", in which all code and data must live within a single 32-bit addressable range. The PLT and GOT sort of provide an out here, so the code only needs to get to the table (which can then get anywhere via an indirection layer).

Quoted 3 lines

This is relevant for Linux modules because it lets us load modules anywhere in the address space. It's also a bit of a headache, as it either requires a GOT+PLT per module (which is big) or merging tables (which is hard).

Quoted 5 lines

I see, thanks! We only get this benefit if we actually do the relevanat indirection in the table, right? And if we merge tables we still have to have all modules within 32 bits of the common table? Is this how some future "medlarge" code model will work, or is it more of a convenient way to reuse existing techniques until other code models are worked out?

The idea is that you'd merge the tables only when it's possible to do that correctly, which is the tricky part.

It'd be called "largeany", the "med" part is what limits the code model to 32 bit offsets. We might just call it "large", as the "any" is kind of redundant.

Quoted 93 lines · Palmer Dabbelt

Quoted 91 lines · shea at shealevy.com

Quoted 80 lines · Palmer Dabbelt

Quoted 64 lines · shea at shealevy.com

Hi Palmer,

Quoted 60 lines · Palmer Dabbelt

Quoted 40 lines · zong at andestech.com

These patches resolve the some issues of loadable module.
- symbol out of ranges
- unknown relocation types

The reference of external variable and function symbols cannot exceed 32-bit offset ranges in kernel module. The module only can work on the 32-bit OS or the 64-bit OS with sv32 virtual addressing.

These patches will generate the .got, .got.plt and .plt sections during loading module, let it can refer to the symbol which locate more than 32-bit offset. These sections depend on the relocation types:
- R_RISCV_GOT_HI20
- R_RISCV_CALL_PLT

These patches also support more relocation types
- R_RISCV_CALL
- R_RISCV_HI20
- R_RISCV_LO12_I
- R_RISCV_LO12_S
- R_RISCV_RVC_BRANCH
- R_RISCV_RVC_JUMP
- R_RISCV_ALIGN
- R_RISCV_ADD32
- R_RISCV_SUB32

Zong Li (11):
RISC-V: Add sections of PLT and GOT for kernel module
RISC-V: Add section of GOT.PLT for kernel module
RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
RISC-V: Support CALL relocation type in kernel module
RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
RISC-V: Support ALIGN relocation type in kernel module
RISC-V: Support ADD32 relocation type in kernel module
RISC-V: Support SUB32 relocation type in kernel module
RISC-V: Enable module support in defconfig
RISC-V: Add definition of relocation types

Quoted 13 lines

 arch/riscv/Kconfig                  |   5 ++
 arch/riscv/Makefile                 |   3 +
 arch/riscv/configs/defconfig        |   2 +
 arch/riscv/include/asm/module.h     | 112 +++++++++++++++++++++++
 arch/riscv/include/uapi/asm/elf.h   |  24 +++++
 arch/riscv/kernel/Makefile          |   1 +
 arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++
 arch/riscv/kernel/module.c          | 175 ++++++++++++++++++++++++++++++++++--
 arch/riscv/kernel/module.lds        |   8 ++
 9 files changed, 480 insertions(+), 6 deletions(-)
 create mode 100644 arch/riscv/include/asm/module.h
 create mode 100644 arch/riscv/kernel/module-sections.c
 create mode 100644 arch/riscv/kernel/module.lds

This is the second set of patches that turn on modules, and it has the same R_RISCV_ALIGN problem as the other one

    http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html

Quoted 8 lines

Quoted 4 lines

It looks like this one uses shared libraries for modules instead of static objects. I think using shared objects is the right thing to do, as it'll allow us to place modules anywhere in the address space by having multiple GOTs and PLTs.

Can you expand on this? It was my understanding that outside of the context of multiple address spaces sharing code the GOT and PLT were simply unnecessary overhead, what benefit would they bring here?

We don't currently have any position-dependent RISC-V code models larger than "medany", in which all code and data must live within a single 32-bit addressable range. The PLT and GOT sort of provide an out here, so the code only needs to get to the table (which can then get anywhere via an indirection layer).

Quoted 3 lines

This is relevant for Linux modules because it lets us load modules anywhere in the address space. It's also a bit of a headache, as it either requires a GOT+PLT per module (which is big) or merging tables (which is hard).

I see, thanks! We only get this benefit if we actually do the relevanat indirection in the table, right? And if we merge tables we still have to have all modules within 32 bits of the common table? Is this how some future "medlarge" code model will work, or is it more of a convenient way to reuse existing techniques until other code models are worked out?

Quoted 5 lines

The idea is that you'd merge the tables only when it's possible to do that correctly, which is the tricky part.

It'd be called "largeany", the "med" part is what limits the code model to 32 bit offsets. We might just call it "large", as the "any" is kind of redundant.

Ah, right, that makes more sense :D. So would "mcmodel=large" also use PLTs/GOTs for long jumps?

Hi Zong,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc5 next-20180314]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url: https://github.com/0day-ci/linux/commits/Zong-Li/RISC-V-Resolve-the-issue-of-loadable-module-on-64-bit/20180314-203750
config: riscv-defconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=riscv

All errors (new ones prefixed by >>):

In file included from include/linux/module.h:25:0,
from fs/notify/fsnotify.c:23:
arch/riscv/include/asm/module.h:38:25: warning: 'struct mod_section' declared inside parameter list will not be visible outside of this definition or declaration
const struct mod_section *sec)
^~~~~~~~~~~
arch/riscv/include/asm/module.h: In function 'get_got_entry':
arch/riscv/include/asm/module.h:40:49: error: dereferencing pointer to incomplete type 'const struct mod_section'

     struct got_entry *got = (struct got_entry *)sec->shdr->sh_addr;
                                                    ^~
   arch/riscv/include/asm/module.h: At top level:
   arch/riscv/include/asm/module.h:89:57: warning: 'struct mod_section' declared inside parameter list will not be visible outside of this definition or declaration
    static inline int get_got_plt_idx(u64 val, const struct mod_section *sec)
                                                            ^~~~~~~~~~~
   arch/riscv/include/asm/module.h: In function 'get_got_plt_idx':
   arch/riscv/include/asm/module.h:91:53: error: dereferencing pointer to incomplete type 'const struct mod_section'
     struct got_entry *got_plt = (struct got_entry *)sec->shdr->sh_addr;
                                                        ^~
   arch/riscv/include/asm/module.h: At top level:
   arch/riscv/include/asm/module.h:101:24: warning: 'struct mod_section' declared inside parameter list will not be visible outside of this definition or declaration
              const struct mod_section *sec_plt,
                           ^~~~~~~~~~~
   arch/riscv/include/asm/module.h: In function 'get_plt_entry':
   arch/riscv/include/asm/module.h:104:53: error: dereferencing pointer to incomplete type 'const struct mod_section'
     struct plt_entry *plt = (struct plt_entry *)sec_plt->shdr->sh_addr;
                                                        ^~

Quoted 1 line

Quoted 1 line

arch/riscv/include/asm/module.h:105:41: error: passing argument 2 of 'get_got_plt_idx' from incompatible pointer type [-Werror=incompatible-pointer-types]

     int got_plt_idx = get_got_plt_idx(val, sec_got_plt);
                                            ^~~~~~~~~~~

arch/riscv/include/asm/module.h:89:19: note: expected 'const struct mod_section *' but argument is of type 'const struct mod_section *'
static inline int get_got_plt_idx(u64 val, const struct mod_section *sec)
^~~~~~~~~~~~~~~
cc1: some warnings being treated as errors

vim +/get_got_plt_idx +105 arch/riscv/include/asm/module.h

    99

100 static inline struct plt_entry *get_plt_entry(u64 val,

Quoted 1 line

101 const struct mod_section *sec_plt,

102 const struct mod_section *sec_got_plt)

   103  {
   104          struct plt_entry *plt = (struct plt_entry *)sec_plt->shdr->sh_addr;

Quoted 1 line

105 int got_plt_idx = get_got_plt_idx(val, sec_got_plt);

106 if (got_plt_idx >= 0)

   107                  return plt + got_plt_idx;
   108          else
   109                  return NULL;
   110  }
   111

---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation