I think what is nice about this project is that it combines everything in a mono repo which is nice for setting up continuous integration and other testing workflows. This project can be used to build toolchains for newlib (bare metal), musl and glibc. It also will allow building qemu and spike (instruction simulation) simulators to allow running RISC-V code without special hardware. It can then run each project's test suites as well as it has some integration tests (dhrystone).
This repo will be useful for getting started with toolchain development. If you are just a user wanting to write c/c++ app code then use your distro's toolchain packages.
I was hoping this would be implemented by actually reading a memory location that was set to 0, when the system is hibernating/sleeping. But it always returns 1. If it was reading a flag from memory it would be useful when examining memory dumps.
The riscv kernel maintainer is not interested in maintaining many different configs for many different SoC. So that is one effort to avoid fragmentation. If you look at the riscv config tree we can see about 5 configs:
I used to live in London (8 years ago) and I did exactly this because of the Jubilee line. I had written a perl program rss.pl that I would give several URLs to generate custom RSS feeds for those websites that provided poor, summary only, feeds. I had it running in a crontab and just posted the feeds to my own webserver. This brings back memories.
I live in Tokyo now where there is internet access everywhere so I retired my perl program.
I wrote this article. As I worked on it I discovered many good resources on Thread Local Storage (TLS), I linked to those in the Further Reading section.
Even with some really good documents it was still hard for me to see the big picture, that's why I drew the diagrams. I hope this article and the diagrams help with others in the future.
Thanks for your feedback, it was a typo (I am pretty bad with those). I changed it to say "The addend from the relocation entry discussed above in the Listing Relocation Entries section".
Addend is actually usually 0 and important as a optimization for directly accessing indexed array values. It is not usually explained very well so I hope its clear now.
If there is anything else that could use clarification I am happy to update the article or answer questions.
Thank you. Yes now I think I understand. I had a follow up question. You state:
">As we saw above, a simple program resulted in 2 different relocation entries just to compose the address of 1 variable. We saw:
R_OR1K_AHI16
R_OR1K_LO_16_IN_INSN"
Can you say why two relocations are needed? I understand the address of x is not known until link time however what would the second relocation be for?
Also is there a good reference for deciphering the relocation names?
Hello, There are 2 relocations because the series of instructions that needs to create a 32-bit memory address requires HI16 and LO_16 relocations. The 2 relocations sure 16-bit high and low bitfields to compose the 32-bit address.
For a full list of relocation types see the list in the last few links of the article. Note, the OpenRISC relocations are not all well documented.
Yes, for OpenRISC as there are no instructions with a 32-bit immediate so we use 2 high and low order relocations. However, on machines like x86 they have variable width instructions and support 32-bit relocations, they can get by with a single relocation entry.
Thanks for pointing that out. As the OpenRISC maintainer of Linux/GCC etc I didn't even know about this effort. Let alone the tool.
I wrote this article with openrisc examples but it is meant to be easy to transfer to other architectures. In the next article I will use both x86 and openrisc examples.
This repo will be useful for getting started with toolchain development. If you are just a user wanting to write c/c++ app code then use your distro's toolchain packages.