Fix linker file for RISCV-64 targets

[romancardenas]

Looks like the current linker file contains some things that were probably required when using binary blobs in riscv-rt. Now that we use inline assembly, they are not needed. Furthermore, some of them appear to provoke errors.

This PR (still WIP) aims to fix these issues. For instance, just commenting out the eh_frame part of the linker script fixes the compilation of the example provided in #196

I still need to play around with this, but this is a good first step

Closes #196

[romancardenas]

I am currently going through cortex-m-rt linker file and checking the differences. I will also assess the size of binaries etc. to evaluate the side effects of any change.

[rmsyn]

Suggested change

	/* .eh_frame (INFO) : { KEEP(*(.eh_frame)) } */
	/* .eh_frame_hdr (INFO) : { *(.eh_frame_hdr) } */
	.eh_frame : { KEEP(*(.eh_frame)) } > REGION_TEXT
	.eh_frame_hdr (INFO) : { *(.eh_frame_hdr) } > REGION_TEXT

This is the suggestion from the linked issue, and also works to resolve the issue.

I think the main problem is that the INFO attribute clears the SHF_ALLOC bit in sh_flags: https://lld.llvm.org/ELF/linker_script.html#output-section-type

The INFO attribute is what looks to have been causing the error, since it was telling rust-lld to not allocate space for the eh_frame and eh_frame_hdr sections. Then, when referenced by another part of code, they were seen as being outside the allocated memory.

So, removing the eh_frame and eh_frame_hdr sections entirely, or removing the INFO section attribute resolves the issue.

Completely removing the sections may be the better option, as it allows downstream users to define them when necessary, without forcing them to place them in the REGION_TEXT region.

[romancardenas]

I plan to work on this PR tomorrow. I hope I can push something reviewable by the end of the day

[romancardenas]

Some differences I found compared to cortex-m-rt:

1. In cortex-m-rt, link.x.in includes memory.x to get the device memory layout. In riscv-rt, BSPs have a board.x linker file that includes both memory.x from PACs and link.x from riscv-rt.
2. In cortex-m-rt, there is only FLASH and RAM regions. In riscv-rt, we have REGION_TEXT (usually an alias of FLASH), REGION_RODATA (usually an alias of FLASH), REGION_DATA (usually an alias of RAM), REGION_BSS (usually an alias of RAM, this region is ficticious), REGION_HEAP (usually an alias of RAM, this region is fictitious), and REGION_STACK (usually an alias of RAM, this region is fictitious).
3. In cortex-m-rt, the linker file usually does things like:

.text _stext :
  {
    __stext = .;
  ...
  . = ALIGN(4); /* Pad .text to the alignment to workaround overlapping load section bug in old lld */
   __etext=.;
  } > FLASH

In riscv-rt, we just use the _stext symbol and forget about the __stext and __etext markers.

[romancardenas]

Also, cortex-m-rt includes an uninit section at the bottom of the RAM. We don't add anything after the stack

[romancardenas]

For the new release of riscv-rt, I would focus on the current changes in the linker file. We can explore other changes for a next iteration, if we think they are valuable

[rmsyn]

L2_LIM is a region distinct from main ram. At least on SiFive U74 cores, this is the SRAM region.

[romancardenas]

I can rescue the previous example in which L2_LIM is used.

[rmsyn]

Do these changes imply incompatibility with application SoCs with multiple HARTs?

Why the change from CPU to microcontroller?

[romancardenas]

I just copy/pasted the docs in cortex-m-rt, the liker should present the exact same configuration as before

[rmsyn]

Would it be possible to support PIC relocation in the future? If it is, this is something I would be interested in working on.

[romancardenas]

It is an interesting research line. Especially for RISC-V 64 targets which currently face issues with static linking (see #153). However, it would need specific code to deal with dynamic linking etc.

[rmsyn]

LGTM