Re: Porting newlib with custom linking

On Fri, Apr 19, 2019 at 3:10 PM Bandhav Veluri
<[email protected]> wrote:
> I'm a newlib beginner trying to write a BSP for a RISC-V manycore processor
> in our research group. Since it is a manycore processor with not so common
> memory layout, it has unique linking requirements. Is there a way I can
> make changes to default linker script so that my changes are also installed
> with the newlib installation?

There are multiple ways to do this.

You can put a target specific linker script file in libgloss and the
end user can use the -T option to add it to the (gcc or ld) linker
command line.  See for instance libgloss/mips/idt32.ld.  This is the
old way of doing this.

You can put a target specific specs file in libgloss, and the end user
can use the --specs gcc command line to add it when linking.  See for
instance libgloss/arm/elf-redboot.specs which refers back to
elf-reboot.ld.  The files get renamed when installed depending on
whether you configure for coff or elf.  A specs file is more flexible
than just a linker script, as you can also modify compiler options,
the redboot one changes the startfiles for instance.  This is the new
way of doing this and is probably the best choice.

You can have your own separate project.  SiFive has
github.com/sifive/freedom-e-sdk for instance where we put all of our
target dependent libraries, linker scripts, etc.

You can define a new configure tuple, e.g. instead of using
riscv64-unknown-elf-gcc you can replace unknown with your target name,
or maybe append your target name to riscv64.  This one is a lot more
work as you would have to modify the configure package to support your
new target, and you may also have to modify binutils, gcc, etc in
addition to newlib to support it.  This is usually only done for new
operating systems, but it is sometimes done for hardware too.  See for
instance the sparc-leon support which points at the
libgloss/sparc_leon dir.  This approach isn't recommended.

Jim