elf2flt: add riscv 64-bits support v2

[floatious]

Hello Mike,

Since I haven't seen any feedback on:
#22

I'm opening a new PR with the latest and greatest.

Kind regards,
Niklas

[cnlohr]

I could really use this (and to add RISC-V 32-bit as well). @floatious , Have you contacted the mailing list, yet uclinux-dev@uclinux.org

[cnlohr]

@floatious are you up for also pulling in the RV32 changes here?

5330503

[franzflasch]

This needs a rebase. Anyone?

[JAicewizard]

This doesn't seem to work compiling a very small program:

$ cat main.c
#include <stdio.h>

void main(){
	printf("HEY");
}
$ riscv64-linux-gnu-gcc main.c -o a.out -r &&  ../elf2flt/elf2flt a.out -v
TEXT -> vma=0x0 len=0x22
DATA -> vma=0x0 len=0x4
../elf2flt/elf2flt: ERROR: text=0x22 overlaps data=0x0 ?

Am I doing anything wrong? I have not worked with elf2flt before. I also tried using it as a linker within GCC, but this produced similar errors (overlapping sections, although different ones).

[JAicewizard]

For future reference, my problems were 2/3(or even 4) fold:
1: pie is not supported
2: build-id is not supported
(3): glibc is not supported, which was kind of to be expected but part of the problem
(4): to actually get a working binary on my system I needed to provide "-Wl,-elf2flt=-r" instead of just "-Wl,-elf2flt"

[wbx-github]

the following patch might be useful for some applications to compile properly:

diff --git a/elf2flt.c b/elf2flt.c
index 6685bff..6b3bea4 100644
--- a/elf2flt.c
+++ b/elf2flt.c
@@ -850,11 +850,21 @@ output_relocs (
                                default:
                                        goto bad_resolved_reloc;
 #elif defined(TARGET_riscv64)
+                               case R_RISCV_NONE:
                                case R_RISCV_32_PCREL:
+                               case R_RISCV_ADD8:
+                               case R_RISCV_ADD16:
                                case R_RISCV_ADD32:
                                case R_RISCV_ADD64:
+                               case R_RISCV_SUB6:
+                               case R_RISCV_SUB8:
+                               case R_RISCV_SUB16:
                                case R_RISCV_SUB32:
                                case R_RISCV_SUB64:
+                               case R_RISCV_SET6:
+                               case R_RISCV_SET8:
+                               case R_RISCV_SET16:
+                               case R_RISCV_SET32:
                                        continue;
                                case R_RISCV_32:
                                case R_RISCV_64:

[gregungerer]

With the recent fixes to the main branch of elf2flt I think this needs a refresh.
My testing shows that really only the single RISC-V nommu patch is now required (that was testing with gcc-13.2, bintutils-2.41 and linux-6.4 - though I tried a couple of older versions of all these as well). It definitely needs Waldemar's update as well to add more of the relocation types.

Can anyone comment on the patch that re-instates the 32-byte alignment? I did not need it for the test cases I tried.

[franzflasch]

@gregungerer I can test this for RISC-V nommu (64 Bit). But I am not sure if I can follow. You mean now this should work with the latest gcc, binutils and linux 6.4? And the only thing missing would be the RISC-V nommu patch from @damien-lemoal?

[floatious]

Can anyone comment on the patch that re-instates the 32-byte alignment? I did not need it for the test cases I tried.

Hello Greg,

looking at the commit message:
90d0c81

The problem was that the ALIGN(0x20) was not performed inside an output section that was being redirected to the flatmem region.

Looking at your commit:
a934fb4

You changed so that the ALIGN(0x20) is once again performed inside an output section that is being redirected to the flatmem region, so the patch that adds the 0x20 alignment should no longer be necessary.

I would argue for extreme caution with having align attributes that are not inside an output section that is being redirected though, as that will most likely reintroduce bugs.

An example seems to be:
https://github.com/uclinux-dev/elf2flt/blob/main/elf2flt.ld.in#L197-L201

I'm quite sure that this can lead to the edata symbol being aligned to 0x10,
and then, bss being aligned to 0x4, but since edata wasn't redirected to flatmem,
edata could be assigned an address that is higher than the address assigned to bss.
(i.e. bss could be assigned an address that is lower than the address assigned to the edata symbol.)

[gregungerer]

Hi Niklas,

On 29/8/23 01:11, Niklas Cassel wrote: Can anyone comment on the patch that re-instates the 32-byte alignment? I did not need it for the test cases I tried. Hello Greg, looking at the commit message: 90d0c81 <90d0c81> The problem was that the ALIGN(0x20) was not performed inside an output section that was being redirected to the flatmem region. Looking at your commit: a934fb4 <a934fb4> You changed to that the ALIGN(0x20) is once again performed inside an output section that is being redirected to the flatmem region, so the patch that adds the 0x20 alignment should not longer be necessary. I would argue for extreme caution with having align attributes that are not inside an output section that is being redirected though, as that will most likely reintroduce bugs. An example seems to be: https://github.com/uclinux-dev/elf2flt/blob/main/elf2flt.ld.in#L197-L201 <https://github.com/uclinux-dev/elf2flt/blob/main/elf2flt.ld.in#L197-L201> I'm quite sure that this can lead to the edata symbol being aligned to 0x10, and then, bss being aligned to 0x4, but since edata wasn't redirected to flatmem, edata could be assigned an address that is higher than the address assigned to bss. (i.e. bss could be assigned an address that is lower than the address assigned to the edata symbol.)

Ok, thanks for the details. Let me look at this in more detail. Regards Greg

…

— Reply to this email directly, view it on GitHub <#24 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIOZ2AOSDLBPB6U5BFYDN3XXSYKHANCNFSM56K7LYWA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[gregungerer]

RISC-V support has been merged into main in later versions of this PR.

[cnlohr]

Thank you.