Sources for the included libgcc.a

[krasin]

Hi Charles,

thank you for working on the ch32v003fun SDK! It's very exciting to be able to use CH32V003 without any proprietary software (if combined with aappleby/PicoRVD).

Would it be possible to provide a link to the sources for the included libgcc.a and the way you built it? I appreciate the included binary as it's very convenient to have everything in place, but I would also like to know how to update this libgcc.a, when necessary.

[krasin]

I took some time to investigate. So, the libgcc.a is a part of newlib and consists of object files with the following signature:

ELF 32-bit LSB relocatable, UCB RISC-V, RVE, soft-float ABI, version 1 (SYSV), with debug_info, not stripped

This matches the RV32V003 architecture, which is RV32EC: 32-bit, embedded, with compression support. Note that the RVE line in the object file signatures signifies embedded. The absent is RVC, for compressed instructions. That's a little suboptimal in terms of code size, but otherwise fine.

I've also built libgcc.a from scratch using the following steps:

1. Install prerequisites (for Debian-based systems; similar steps for other systems):

sudo apt-get install build-essential autoconf automake autotools-dev curl \
libmpc-dev libmpfr-dev libgmp-dev gawk build-essential bison flex texinfo \
gperf libtool patchutils bc zlib1g-dev git

2. Checkout sources:

git clone --recursive https://github.com/riscv/riscv-gnu-toolchain.git
cd riscv-gnu-toolchain

3. Configure and build:

./configure --prefix $(pwd)/build-ch32v003 --with-arch=rv32ec --with-abi=ilp32e
make -j8

4. Enjoy the built libgcc.a:

$ find ./build-ch32v003 -name libgcc.a
./build-ch32v003/lib/gcc/riscv32-unknown-elf/12.2.0/libgcc.a
$ ls -sh ./build-ch32v003/lib/gcc/riscv32-unknown-elf/12.2.0/libgcc.a
<...> 2663918 <...> ./build-ch32v003/lib/gcc/riscv32-unknown-elf/12.2.0/libgcc.a

The new library is 2663918 bytes. That's a little bit smaller than the libgcc.a checked into this repository, which is 2932544 bytes. The reason seems to be because the version I built supports compressed instructions, so they naturally take a bit less space:

ELF 32-bit LSB relocatable, UCB RISC-V, RVC, RVE, soft-float ABI, version 1 (SYSV), with debug_info, not stripped

I've verified that libgcc.a that was built using the instructions links fine with every example I tried, except self_modify_code, but that example seems to be broken with the existing libgcc.a as well, so it's not related.

@cnlohr would you be open to a pull requests that adds a concise version of instructions on how to build libgcc.a near misc/libgcc.a? I will be happy to make one.

Additionally, if you are interested in saving some bytes, I can also include the libgcc.a that has the compressed instructions baked in. Frankly, the savings are likely to be minor (within 10%), but when we only have 16 KB flash, maybe it would actually matter for some people?

[cnlohr]

I would absolutely be up for it!!!! And if your new libgcc is better in (basically any way) then we should use it. I just found a totally random libgcc. I don't even remember where it came from.

Please make the PR, @krasin

[prosper00]

I'm curious why it needs to be provided. I mean, if its part of the toolchain already, shouldn't everyone already have it? I mean, gcc itself, newlib and co - they're not provided, but are assumed to be present

[krasin]

@cnlohr will do! Thank you for the encouragement.

@prosper00 on Linux, it's not needed as gcc-riscv64-linux-gnu package has all/most necessary libgcc.a variants available:

$ find /usr/ -name 'libgcc.a'
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv32imafc/ilp32f/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv32imf/ilp32f/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv64ifd/lp64d/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv32if/ilp32f/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv64if/lp64f/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv32imafdc/ilp32d/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv64imf/lp64f/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv64iaf/lp64f/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv32im/ilp32/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv64imafc/lp64f/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv32emac/ilp32e/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv32e/ilp32e/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv64i/lp64/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv32i/ilp32/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv64iac/lp64/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv32imfd/ilp32d/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv64ia/lp64/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv64iafd/lp64d/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv32iac/ilp32/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv32iaf/ilp32f/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv32eac/ilp32e/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv32iafd/ilp32d/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv64im/lp64/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv32ea/ilp32e/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv32imac/ilp32/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv64imac/lp64/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv32ia/ilp32/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv32em/ilp32e/libgcc.a
/usr/lib/gcc/riscv64-unknown-elf/12.2.0/rv32ifd/ilp32d/libgcc.a

README.md says: "An extra copy of libgcc so you can use unusual risc-v build chains, located in the misc/libgcc.a", but I hope that @cnlohr can elaborate more about that.

[krasin]

@cnlohr thank you for merging.

1. It's possible that I've missed something during my testing and that the replacement libgcc.a is "bad" in some way. Please, do not hesitate to rollback my change, if in doubt.

2. @prosper00 raised a good point that bundling libgcc.a is not generally a thing. Would it be possible to give an example, where it's actually needed? This is completely optional, but might serve as a good reference point in the future. Thanks!

[cnlohr]

You mention needing to elaborate on that? Do you have a recommendation for what verbage we could use to clarify why one would want to use our build copy of libgcc?

[krasin]

Hi @cnlohr ,

is there any particular use case / toolchain that you encountered and that's missing an appropriate libgcc.a? In the README.md you mention "unusual risc-v build chains", is there an example of that?

Overall, it's all pretty minor.

Thanks again for working on ch32v003fun!

[cnlohr]

On the Windows compiler I recommend, there is no -EC libgcc included with it. So I threw it in.

[krasin]

I see, thanks.