[PATCH 0/1] fs: binfmt_elf.c:elf_core_dump() link error on RV32 platform without optimization

[PATCH 0/1] fs: binfmt_elf.c:elf_core_dump() link error on RV32 platform without optimization

[Ruinland Chuan-Tzu Tsai]

Hi all,

Just as the mail title, recently on RISC-V 32bit platform, I've been
encountering linking errors when building a certain part of Kernel,
`fs/ext4/extents.c`, without optimization (-O0) for debugging .

The error message GNU ld giving out indicates that it fails to resolve
undefined symbol "__divdi3", which is one of integer library routines
shipped by libgcc.

After conducting an autopsy, I can locate the root cause is that the
roundup() macro, which does division on 64bit data, is used inside
`fs/ext4/extends.c:elf_core_dump()`. Unfortunately, it's highly unlikely
to fit 64bit data into instruction encoding space on 32bit machines,
hence GCC will try to use its own software routines inside libgcc and
causing the linking error mentioned above.

Yet with default optimization level "-O2", the logic could be optimized
into bitwise instructions ("shift" and "and").Thus the linking error
won't occur.

Though I can kludge the build process by modifying
`scripts/link-vmlinux.sh:vmlinux_link()` to force it link kernel
against libgcc.a, still I'm wondering if it's desirable to work this
issue out by either :

(1) replacing `roundup()` with `round_up()` since `ELF_EXEC_PAGESIZE`
must be the power of 2. (The attached patch.)

or
 
(2) duplicate the logic from `roundup()` and use kernel-provided
`div_s64()` instead of plain division. The most recent relating patch I
saw is 013ad043, which takes this approach.

In my humble opinion, even it's understandable to expect a reasonable
level of optimization in the real world just as glibc expects at least "-Og"
is used, still, I feel absurd to depends on the optimization on
"replacing division with shift and and" to save the day.

Cordially yours,
Ruinland

-- 
2.17.1

[PATCH 0/1] fs: binfmt_elf.c:elf_core_dump() link error on RV32 platform without optimization

[Ruinland Chuan-Tzu Tsai]

Hi all,

Just as the mail title, recently on RISC-V 32bit platform, I've been
encountering linking errors when building a certain part of Kernel,
`fs/ext4/extents.c`, without optimization (-O0) for debugging .

The error message GNU ld giving out indicates that it fails to resolve
undefined symbol "__divdi3", which is one of integer library routines
shipped by libgcc.

After conducting an autopsy, I can locate the root cause is that the
roundup() macro, which does division on 64bit data, is used inside
`fs/ext4/extends.c:elf_core_dump()`. Unfortunately, it's highly unlikely
to fit 64bit data into instruction encoding space on 32bit machines,
hence GCC will try to use its own software routines inside libgcc and
causing the linking error mentioned above.

Yet with default optimization level "-O2", the logic could be optimized
into bitwise instructions ("shift" and "and").Thus the linking error
won't occur.

Though I can kludge the build process by modifying
`scripts/link-vmlinux.sh:vmlinux_link()` to force it link kernel
against libgcc.a, still I'm wondering if it's desirable to work this
issue out by either :

(1) replacing `roundup()` with `round_up()` since `ELF_EXEC_PAGESIZE`
must be the power of 2. (The attached patch.)

or
 
(2) duplicate the logic from `roundup()` and use kernel-provided
`div_s64()` instead of plain division. The most recent relating patch I
saw is 013ad043, which takes this approach.

In my humble opinion, even it's understandable to expect a reasonable
level of optimization in the real world just as glibc expects at least "-Og"
is used, still, I feel absurd to depends on the optimization on
"replacing division with shift and and" to save the day.

Cordially yours,
Ruinland

-- 
2.17.1


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

[PATCH 1/1] Modifying fs/binfmt_elf.c:elf_core_dump() to use round_up()

[Ruinland Chuan-Tzu Tsai]

Since roundup() will use plain division which might cause the compiler
to use its own integer library routines (i.e. __divid3() in libgcc) on
32bit mahcines when "O0" is specified. The problem won't occur if it
uses round_up() which utilize bitwise operations (shift & and), and the
limitation that "the divisor must be the power of 2" is true on
ELF_EXEC_PAGESIZE.

Signed-off-by: Ruinland Chuan-Tzu Tsai <ruinland@andestech.com>
---
 fs/binfmt_elf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index b12ba98ae..01d4d6d2b 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -2209,7 +2209,7 @@ static int elf_core_dump(struct coredump_params *cprm)
 		offset += sz;
 	}
 
-	dataoff = offset = roundup(offset, ELF_EXEC_PAGESIZE);
+	dataoff = offset = round_up(offset, ELF_EXEC_PAGESIZE);
 
 	offset += vma_data_size;
 	offset += elf_core_extra_data_size();
-- 
2.17.1

[PATCH 1/1] Modifying fs/binfmt_elf.c:elf_core_dump() to use round_up()

[Ruinland Chuan-Tzu Tsai]

Since roundup() will use plain division which might cause the compiler
to use its own integer library routines (i.e. __divid3() in libgcc) on
32bit mahcines when "O0" is specified. The problem won't occur if it
uses round_up() which utilize bitwise operations (shift & and), and the
limitation that "the divisor must be the power of 2" is true on
ELF_EXEC_PAGESIZE.

Signed-off-by: Ruinland Chuan-Tzu Tsai <ruinland@andestech.com>
---
 fs/binfmt_elf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index b12ba98ae..01d4d6d2b 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -2209,7 +2209,7 @@ static int elf_core_dump(struct coredump_params *cprm)
 		offset += sz;
 	}
 
-	dataoff = offset = roundup(offset, ELF_EXEC_PAGESIZE);
+	dataoff = offset = round_up(offset, ELF_EXEC_PAGESIZE);
 
 	offset += vma_data_size;
 	offset += elf_core_extra_data_size();
-- 
2.17.1


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