Re: Troubles building cross-compiler; target 64-bit RISC-V

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Aug 6, 2019 at 3:23 AM <64m@xxxxxxxxxxxx> wrote:
> It worked. I had to specify program-prefix option. I am just curious, what is the difference between riscv64 and riscv64-elf targets. Binutils accepts both. I am able to produce ELF executable using both.

Using elf for the OS field is the traditional way to specify that a
target is an embedded ELF target.  We used to have support for the
AOUT, COFF, and/or ELF object file formats for many targets, so
mentioning the object file type was important.  But nowadays most
people use ELF, and some people think that it shouldn't be necessary
to specify the object file format anymore, and have started using none
for the OS field.  If you configure for "riscv64" this canonicalizes
to riscv64-unknown-none because you didn't specify the OS/object file
format.

The binutils configure support checks for operating systems like linux
first, and then it has a catchall case to match riscv*-*-* which will
match both riscv64-unkinown-elf and riscv64-unknown-none.  So binutils
will currently handle none exactly the same as elf.  The gcc configure
support checks for operating systems like linux and freebsd, and then
it checks for riscv*-*-elf.  So gcc will not accept riscv64 or
riscv64-none as a configure target.  It only accepts riscv64-elf.
There is one special case in gcc configury where it checks for "-elf*"
in the configure triplet, and then assumes that the target is using
newlib, and sets some makefile variables to improve gcc and newlib
interaction.  This does not happen if you use none for the OS.

Currently, the riscv port only supports ELF, but I think it would be
short sighted to assume that ELF is the only object file format that
will ever be supported.  What happens if someone invents a new object
file format better than ELF?  What happens if someone decides to do a
RISC-V Windows port and adds RISC-V COFF support?  Or what if someone
adds COFF support for a RISC-V UEFI port?  If any of those happen,
then none becomes ambiguous and becomes a potential problem.  So I
personally prefer to continue using riscv64-elf for embedded
toolchains.  But if people think using none is better the gcc
configury could be fixed to make this work.

Jim



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux