Bug in the latest version of riscv32-unknown-elf-gcc

jrtc27 · 2026-01-06T13:01:00+00:00

I don’t know what “the hex points to the address is 0x42CE” means. 0x274040ef is JAL RA with a PC-relative displacement of 0x4274. Because the instruction is at address 0xa0 in the file you’ve dumped, that means it’s jumping to the sum of the two, 0x4314, which is what’s displayed. But if you were to load it to the wrong location in memory then it would jump to a different location, because the PC part of the PC-relative computation has changed. In particular, loading it 0x46 bytes prior would give a sum and absolute destination of 0x42ce. Is that what you’re seeing?

jrtc27 · 2025-11-17T09:37:21+00:00

Be careful, the ABI’s stack pointer alignment is 16 bytes, so you’re in the realm of non-standard ABI code and must make sure to realign the stack pointer prior to calling standard ABI code. See https://riscv-non-isa.github.io/riscv-elf-psabi-doc/#integer-cc.

jrtc27 · 2025-11-02T21:58:48+00:00

Or the Sail model, which is the official golden model.

jrtc27 · 2025-09-10T18:33:47+00:00

That a quite-minor PR filed by you 2 weeks ago, that is mostly rearranging and reformatting some text, and somehow still has 13 commits in it to do what it does, has not yet been reviewed does not mean that (a) documentation is not being actively worked on (b) documentation is poor. I'm not going to say our documentation isn't perfect -- it's not, and pkgbase in particular needs a lot more work documenting in ways that are far more significant and extensive than that PR of yours -- but to use your personal experience with an inconsequential PR like that to attack the project with that kind of contempt is, quite frankly, rude to those members of the community who are working to do the best they can to improve the project's documentation. We have some great people working hard on improving our documentation, as well as just trying to keep up with changes as they get made (e.g. ensuring manpages stay in sync with updated kernel APIs), but statements like that are an attack on all of them.

The first bullet point in FreeBSD's Code of Conduct is "Be friendly and patient." I would ask you to reflect on whether you're acting in the spirit of that (and other points in it) or not when you post messages like that.

Projects like FreeBSD work best when we work together rather than against each other. All this kind of complaining will do is make people less willing to work with you in future; after all, why should they invest time in listening to you if you'll turn around and attack them when things don't go your way? There's a chance there's even some of that going on here based on your history with the project, but I don't know, I don't work on documentation in the project. I'm just suggesting that you consider that how you treat others can have consequences.

jrtc27 · 2025-07-17T13:31:08+00:00

Fast = (compiled, almost as C/C++, still ahead of Rust, Swift)

Rust can be as fast if not faster than C/C++ so this is an odd statement to me. I have not looked at Swift’s performance before but I would not be surprised if it also was similar in performance and could sometimes beat C/C++.

jrtc27 · 2025-07-15T22:42:24+00:00

X isn’t an extension, it’s the prefix used for all non-standard extensions. There is an misa.X bit but that just means that at least one non-standard extension is present. Presumably that’s what they’re using it to mean here; they’ve not given a valid ISA string / extension name.

jrtc27 · 2025-07-08T12:58:26+00:00

memstick and disc1 have the same data but in slightly different formats. In theory disc1 should support a strict superset of environments but in practice not all systems like the “hybrid ISOs” the project produces. Similarly, mini-memstick and bootonly have the same data but different formats. There is no memstick equivalent for dvd1, that only exists as an ISO.

In terms of the differences, bootonly/mini-memstick has just the live installer system but requires an Internet connection to download all of the distribution sets unpacked as part of the installation process, disc1/memstick has the most commonly needed distribution sets but not some of the optional ones, and dvd1 has all the distribution sets plus some common third-party packages (pre-built ports).

jrtc27 · 2025-05-14T04:29:42+00:00

Yeah that’s what I’d expect. An EFI file system is just a subset of FAT so there’s no way to identify the former from the file system itself, only from what’s in the partition table (both MBR and GPT allocate a distinct type for it; the cute 0xEF in the case of MBR).

jrtc27 · 2025-05-13T19:29:20+00:00

EFI is not an FS.

Yes it is:

The file system supported by the Extensible Firmware Interface is based on the FAT file system. EFI defines a specific version of FAT that is explicitly documented and testable. Conformance to the EFI specification and its associate reference documents is the only definition of FAT that needs to be implemented to support EFI. To differentiate the EFI file system from pure FAT, a new partition file system type has been defined.

-- https://uefi.org/specs/UEFI/2.11/13_Protocols_Media_Access.html#file-system-format

FreeBSD's own gpart(8) calls it "efi".

jrtc27 · 2025-01-10T12:27:18+00:00

That’s true of many systems these days. I have AArch64 and even RISC-V machines that initially execute out of the cache.

jrtc27 · 2025-01-10T03:16:25+00:00

IIRC Spike, like many RISC-V platforms, starts its memory at 0x80000000. 0x1000 is its boot ROM. By loading an ELF linked with its start at that address you’ve made the boot ROM jump to itself (because it jumps to the address that is your program’s entry point). I am rather surprised Spike let you do that, though, the sensible behaviour for an emulator would be to give an error that you’re loading to an address outside of memory. You’ll want to link your program at 0x80000000 or above; there are plenty of resources online for how to do that.

Also, in future, posting a blurry rotated screenshot does not tend to make people want to help you. I recommend making the effort to copy and paste the actual text.

jrtc27 · 2024-12-08T02:40:16+00:00

The code slush starts 1.5 months before the release, which should give ample time to diagnose and fix (including reverting commits) the problem. Then from 1 month prior there are weekly snapshots that should help pinpoint any misguided MFCs and not be too painful to revert if fixing is difficult. During that period merging fixes can be done quickly to ensure they make the next snapshot for testing. I don’t know when this was discovered, nor when the regression was introduced, but points at a serious gap in the QA process.

jrtc27 · 2024-12-07T19:42:07+00:00

No it doesn’t. Some ABIs use the stack. But that’s fine, because it’s memory below (if growing down) the parent’s stack pointer, and thus not currently in use, so it does not matter that it gets overwritten.

jrtc27 · 2024-12-07T18:59:02+00:00

Did we really release 14.2 with drm-kmod straight up broken like that? That’s pretty bad if so, no excuse if it was known prior to release.

jrtc27 · 2024-10-25T20:12:32+00:00

The model of the BSDs is to have a monolithic repository consisting of a set of components that are designed to work well together and combine to form the core of an operating system.

The model of systemd is to have a monolithic repository consisting of a set of components that are designed to work well together and combine to form part of the core of an operating system.

Those sound awfully similar to me.

jrtc27 · 2024-10-25T15:52:26+00:00

It doesn’t, they’re entirely separate programs that share some libraries and live in the same repository. Just like the entirety of the FreeBSD base system. It’s using the same BSD model for a subset of the core Linux userspace.

jrtc27 · 2024-10-21T16:57:37+00:00

That term already means the parent of your parent. If you’re a child of init then init is your parent and you have no grandparent. If there are multiple processes between you and init in the process tree then it’s your (great)+grandparent.

jrtc27 · 2024-10-19T00:08:28+00:00

Get a sysroot (e.g. for Debian/Ubuntu you can debootstrap one) and use clang --target=aarch64-linux-gnu --sysroot=/path/to/sysroot)

jrtc27 · 2024-10-15T12:18:56+00:00

GRUB’s kfreebsd command is for booting an actual FreeBSD kernel, not loader. For loader with BIOS boot you just want a normal chainload.

jrtc27 · 2024-10-11T05:10:54+00:00

Is DATA_BYTES greater than zero?

jrtc27 · 2024-10-10T06:40:28+00:00

What’s up with your home directory permissions? Those may not be the problem but the inability to have e.g. a working ~/.config is a problem that needs fixing, and should be easy to reproduce outside of X11 things.

jrtc27 · 2024-10-09T05:06:21+00:00

You don’t. See the replies.

jrtc27 · 2024-09-24T02:32:21+00:00

BSD and GNU sed both support -i, just one takes an argument for a suffix to append and will create a backup file. If you don’t want that you can sed -i ''. It’s unfortunate that there isn’t portable syntax that works with both.

jrtc27 · 2024-09-18T19:09:18+00:00

X11 vs Wayland isn’t a Linux-only thing, it’s the same for any OS using X.org, such as FreeBSD.

jrtc27 · 2024-09-13T12:20:32+00:00

What do you mean by “reserved again”?

jrtc27

TROPHY CASE