Re: Porting newlib with custom linking

[Bandhav Veluri <bandhav dot veluri00 at gmail dot com>]

Thanks a lot Jim! Yes, specs file feels like an elegant way to do it. Is
there a way I can edit the default specs file?

We are working on a fork of riscv-newlib and intend that installation of
our newlib to be separate. So it's okay to change the default behaviour of
gcc.


On Sun, Apr 21, 2019, 7:49 AM Jim Wilson <jimw@sifive.com> wrote:

> On Fri, Apr 19, 2019 at 3:10 PM Bandhav Veluri
> <bandhav.veluri00@gmail.com> 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
>