Debian package

[pbreuer]

tar of a linux debian/ subdir attached. With this one need only run debuild in the source directory (more or less; it will want a ../spike_1.1.1.orig.tar.gz file, but you'll make that from the original source) to build an installable debian .deb package. I have built against your source from git commit b81b5a0 .
I modified Makefile.in very slightly to install libs in /usr/lib/cpu-vendor-os instead of /usr/lib.
I've done this because your offering for the riscv standards area is about the only one that makes any sense as an installable thing to me. I don't know yet what it does (it looks like a simulator? What's wrong with verilator?). Everything else I have looked at in the standards area is completely uninstallable in a linux distro, basically for relying on python that will not install and "documents" that contain only system engineer level gibbereze with self-referential assumptions. I have resorted to generating whatever files seem to be required for whatever it all/anything does myself. With your offering I hope to be able to find out more of what is needed, in order to supply it (if somebody would tell me what thing and format ref.elf.dump etc are supposed to be, I would be very, very, very grateful, I have successfully generated all the ref.elf directly from the .S originals scattered about the riscof, etc. directories, modulo a correction to gcc's treatment of large .align numbers).
I won't install anything unless it is done properly, globally for the system, and known to the system packaging structure. Hence the debian packaging. Caveat: I know next to nothing about debian packaging, I am not and never have been and never will be a debian packager, but I can hack away with anyone. This debianization will likely work with other architectures than x86_64 if one adds them to the appropriate line in the debian/control file. I'm not trying it. Please feel free to improve. I guessed a lot of what went into the changelog file and formatted it badly. Check licensing (BSD?). It should cause no trouble to just add it in to your source. It's not involved with your ordinary source. The change to the Makefile.in is a patch that debuild will apply when one runs debuild, not otherwise. I guess one can deduce that ... this tar contains nothing but the new debian/ subdir and its files.
spike-debian.tar.gz

PS. Having installed it properly, I can now read the docs. Yes, this is a simulator. But what is that about a "proxy kernel"? I want a simulation of a machine, not of an operating system running on a machine.

I suspect this is more or less a state machine running user-level riscv machine code. Is that it? The code would contain a single big loop executing riscv machine code instructions that modify 32 general registers and some system configuration registers (CSRs). For system call instructions, I suppose the code then calls out to the operating system. Ditto for load and store instructions. But is there an emulation of a programmable data TLB and instruction TLB? That would require responding to whatever instructions nowadays access the TLBs. I need just the barebones machine.

That you are loading plain elf files is great, but what address range am I supposed to tell them to load at? I suppose it doesn't matter as you are presenting a full and complete virtual address space, backed lazily by the external operating system. So whatever I ask for, I will (apparently) get!

Am I right or am I right?

Then the basic question I need to ask is how do I use your emulation to test the .S files found in the riscof directories. They test individual riscv instructions. I haven't read through any one completely, but my impression from the glances I gave at the codes is that they set up registers, run the instruction, then examine the registers, and ... I don't know what or how they output, or what that should be compared with. They're mostly in user mode, but they do some fiddling in supervisor mode to start with, and presumably end with, since they have interrupt vectors and so on. If you can tell me what the riscov files need to be turned into in the way of ref.elf.dump and so on, I would be grateful, even if they can't run as is on your state machine.

[trdthg]

I don't know much about the situation with spike, but I found this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040380
Opposing opinions that have appeared before

[pbreuer]

On Wed, 08 Jan 2025 23:38:05 -0800 MingZhu Yan ***@***.***> wrote: I don't know much about the situation with spike, but I found this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040380 Opposing opinions that have appeared before

Nobody is asking you to package spike for debian! Just to add the debian packaging subdirectory to your distributed code so that users of spike can package it for their OWN debian system, or other system (one can change package formats eaily with "alien"). I won't install anything that is not under package management. No packaging info prepared, no install. Regards PTB

[pbreuer]

On Wed, 08 Jan 2025 23:38:05 -0800 MingZhu Yan ***@***.***> wrote: I don't know much about the situation with spike, but I found this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040380

Actually looking at that exchange you might as well just ask Jax Young ***@***.***> if he did do the packaging for his own "ppa" in the end. That would beat my very amateur quick and dirty effort at a debian/ info subdir for your code, I'm sure! It's just documentation! It's not something you need to worry about other than check the info in it is to your liking. You can improve it, or others can improve it, some other time. The point is that it should be there so it can be improved.

Opposing opinions that have appeared before

Not relevant to you, however! You think spike is just fine! That debian maintainer (Jessica) seems to be a touch on the hardware engineer side of things. There is no big reason for a working, legal, compliant, package NOT to be in debian other than that a debian maintainer cannot be found bribed or persuaded to maintain it. But we/you/I don't care about that. It's your code. You can put a debian info subdirectory in it and that will help end users, not debian maintainers! (They'd priss about everything in sight when let loose on a package ... experience says! Rules, rules, rules, ...). Regards PTB