GVSDS/ViperOS
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
268 Commits 1 Branch 0 Tags
b9efc30d7134dcbeefe8313701f045169de6d49f
Commit Graph
19 Commits
Author SHA1 Message Date
TermiNexus 97ca7bbbdb chore(build): viperc 路径集中为 VIPERC 常量并切换 vpcbuild3 
- BuildKernel / BuildLibs / BuildApps 共用 VIPERC，去掉三处硬编码
- 指向 ViperC/__vpcbuild3__/output/viperc.exe
 2026-10-27 12:43:19 +08:00
TermiNexus ca448eee98 chore(build): 移除 VPUI64 动态库并调整构建入口 
- 删除 Libs/VPUI64（linker.ld / project.vpj / vpui64.vp），同步 README
- viperc 路径改到 ViperC/__vpcbuild__/output
- 新增 --nokernel（显式 --kernel 优先，且与 --kernel-only 互斥）
- 未编内核时的提示改为「跳过内核编译」
 2026-10-26 22:41:47 +08:00
TermiNexus d19d96dc70 build: 默认重编内核，--app 时才跳过 
上一轮把默认改成不编内核，导致内核侧修复（键盘解码/诊断）没进产物，日志与代码对不上。恢复为：不带 --app 时默认编内核 + 库 + 全部应用；--app=a,b 视为只迭代应用（跳过内核），需要内核时显式加 --kernel。
 2026-10-17 15:36:56 +08:00
TermiNexus 465ef4a910 feat(build): 新增 --app=a,b 只编指定应用；默认不重编内核 
默认行为改为**不重编内核**（多数迭代只改应用/库），需要时显式加 --kernel；--app=hello,explorer 只编译列出的应用（逗号分隔），不带 --app 仍编译全部应用；新增 --libs 显式编译 Libs 下的 .so（带 --app 时默认跳过库，要一起编就加 --libs）；应用/库编译改为表驱动（APP_LIST/LIB_LIST），--noapp 的拷贝逻辑抽到 CopyExisting()。
 2026-10-16 22:41:28 +08:00
TermiNexus 6bd2390e08 feat(explorer): S2 —— 新增图形壳应用 explorer 骨架，用户态经 devfs+mmap 直接写屏 
Apps/Explorer：复制标准 app 骨架（main.vp / linker.ld / project.vpj，链接地址 0x400000）。启动流程：open /dev/fb0 → ioctl(FB_GET_INFO) 打几何 → mmap 拿到线性地址 → 等约 2 秒（等内核桌面首屏全量重绘过去）→ 画一条渐变横条验证像素真上屏 → open /dev/input/keyboard|mouse 验证输入设备可达 → 常驻不退出。

vpsdk/devfs.vp（新增 SDK 设备层）：设备路径常量（与内核注册名逐字一致）、FB_GET_INFO 与 FbInfo 镜像（packed，与内核同布局）、fb_open/fb_get_info/fb_map/kbd_open/mouse_open。

build.py：把 Explorer 加进 required_apps 清单与完整构建分支；内核 main.vp 在四个 app 之后 spawn /APPS/explorer.elf。内核 desktop 与 explorer 并存属迁移中间态，S3 会把窗口合成整体交出去。
 2026-10-16 18:43:13 +08:00
TermiNexus 424233dcea chore(build): QEMU/OVMF 改为 code 只读 + 独立可写 vars 副本 2026-10-16 16:40:41 +08:00
TermiNexus e6aabf5cf2 feat(build): build.py 支持 --onlyapp（只编译库与应用，跳过内核） 
只改应用/库时可省去内核编译时间：--onlyapp 时跳过 BuildKernel，其余（BuildApps /
BuildBootloader / BuildDisk / RunQemu）照常。与 --onlyrun 不冲突（--onlyrun 优先级更高，
完全跳过构建）。依旧可与 --noclean / --noapp / --kernel-only 组合。
 2026-10-14 15:34:40 +08:00
TermiNexus 8b0d24e0d5 feat(build, kernel): 内核链接直接产出带符号 kernel.elf，再由 objcopy 二次产出 kernel.bin 
按方案调整：
- VKernel/project.vpj：linker 去掉 --oformat binary / --strip-all，output 改为 kernel.elf。
- build.py：用 objcopy -O binary --set-section-flags .bss=alloc,load,contents 由 kernel.elf
  二次产出 kernel.bin，再拷到 disk/。同源产出 ⇒ 两者布局逐字节一致，日志里的 rip 可直接用
  objdump / nm / readelf 落到函数名；原来那段依赖 phase2cmd.bat 的改写字样已整体删除。
- --set-section-flags .bss=...contents 把 .bss 一并写进裸镜像（ELF 里 .bss 默认 NOBITS），
  于是 bootloader 按“文件大小”预留即可覆盖 .bss（boot.c 里另有 256KB 余量，双保险）。
- linker.ld：移除此前对 lld 无效的 LONG(0) 写法，.bss 恢复为干净定义。

注意：需完整重编（不能只 --onlyrun）才会生成新的 kernel.elf / kernel.bin。
 2026-10-14 15:22:05 +08:00
TermiNexus 1ebb744418 fix(boot, build): bootloader 预留补上内核 .bss（多留 256KB）；build 跳过路径过期的 kernel.elf 
崩溃症状：paging.init 清 CR0.WP 的窗口里遍历页表时 #GP（cr0=0x80000033 → WP=0），
随内核体积变化时有时无。

根因分析（已实测确认）：kernel.bin 由 ld.lld --oformat binary 产出，链接脚本里那条
“强制 .bss 为 PROGBITS”的写法对 lld 无效 —— 实测 kernel.bin 只有 249088 字节（0x3CD00），
而 .bss 结尾在 ~0x14B900，即约 60KB 的 .bss 尾部并未写进文件。bootloader 只按文件大小
预留物理页（61 页 → 0x100000..0x13D000），于是 .bss 尾部落在未预留的 EfiConventionalMemory
中：bootloader 自身的分配（页表、缓冲等）可能落进去，内核一写 .bss 就把它们破坏 ——
表现就是 paging.init 遍历到被破坏的页表项而 #GP，且随体积变化“时有时无”。

修改：
- boot/boot.c：PagesNeeded 在文件大小之外显式多预留 64 页（256KB），覆盖 .bss 并留余量。
- build.py：生成 kernel.elf 前逐个校验 .bat 里的 .obj 是否存在，缺失即跳过并给出提示
  （--rebuild-includes 后 includes.binary_mlir 下目标文件名会变，.bat 路径会过期）。

注意：本修复需要同时重编 bootloader（python build.py --bootloader）才生效。
 2026-10-14 15:17:13 +08:00
TermiNexus 59ba295532 feat(build): build.py 支持 --onlyrun（跳过编译/打包，复用现有 disk.img 反复跑 QEMU） 
为反复复现偶发写坏提供快速通道：脚本拆成 BuildKernel / BuildApps / BuildBootloader /
BuildDisk 与 RunQemu 五段，--onlyrun 时只执行 RunQemu（清空 serial.log → 启动 QEMU →
打印串口日志），不再重编内核/应用/引导器、也不再重新打包 disk.img。行为与原来完全一致，
只是把“构建段”与“运行段”分开，便于跳过前者。用法可直接循环：python build.py --onlyrun
 2026-10-14 15:01:30 +08:00
TermiNexus 21f4a6aeca fix(build): kernel.elf 链接命令改写做稳健化，避免误覆盖 kernel.bin 
原改写用字面 replace("--oformat binary"/"kernel.bin")，若 .bat 里的写法是
"--oformat=binary" 或输出名大小写/路径不同就会匹配不中——那种情况下执行的
仍是原始命令，会把 kernel.bin 覆盖成非预期产物。现改为正则同时兜住
"--oformat binary"/"--oformat=binary"、"-o <path>"/"--output=<path>"，
并加保护：改写后若不包含 kernel.elf 则直接跳过，绝不执行未改写的命令。
 2026-10-14 13:47:36 +08:00
TermiNexus 449f2dbc37 fix(mm): 加分配失败分步诊断；build.py 改用 --phase2command 产出 kernel.elf 
- mm.vp: 在 malloc(slab 路径)、_create_page、allocate_block 三处失败分支各加一条
  [mm] 诊断打印，用于定位“[desktop] dirty_rows malloc FAILED”
  （768B → ≤SLAB_THRESHOLD → slab size class 5(1024B) → _create_page 需 order≥1 伙伴块；
   DumpBuddy 显示伙伴空闲链健康，故需进一步区分是哪一步返回 NULL）
- build.py: kernel.elf 改为调用 viperc --phase2command 拿到“精确链接命令”再改写产出。
  自行 glob .obj 去链会因对象顺序不同得到与 kernel.bin 不一致的段布局
  （实测前 247KB 里 230KB 不同），无法把日志 rip 映射回函数。
 2026-10-14 13:36:01 +08:00
TermiNexus 54e88ce957 feat(build): 额外链接带符号 kernel.elf；mm 增加 DumpBuddy 诊断 
- build.py: 用同一批 .obj + 同一 linker.ld 再链一份
  VKernel/__vpcbuild__/output/kernel.elf（仅去掉 --oformat binary/--strip-all），
  段布局与 kernel.bin 一致 → 可把日志里的 rip 用 objdump/nm 映射回函数
- mm.vp: 新增 export DumpBuddy()，打印 arena start/end 与 total/used/free
  及各阶空闲链表首块（上限 8 个），定位分配失败是“链表空”还是“块指针坏”
- main.vp: mm.init 之后、desktop.start 之前各调一次 DumpBuddy()，
  用于排查“[desktop] dirty_rows malloc FAILED”
  （768B → ≤SLAB_THRESHOLD → slab size class 5(1024B) → _create_page 需 order≥1 伙伴块）
 2026-10-14 13:27:40 +08:00
TermiNexus 091efd11fc chore(build): build.py 增加 --bootloader（make -C boot / GNU-EFI） 
bootx64.efi 不由 viperc 产出，长期停留在旧件——改了 boot.c 却仍在用旧引导器
（本次即踩到：boot.c 的栈区占位因 bootloader 未重编而未生效）。
- 传 --bootloader 时执行 make -C boot（MSYS make → WSL Ubuntu → objcopy 直接
  产出 disk/EFI/BOOT/bootx64.efi）
- 未传时若 boot/boot.c 比 disk/EFI/BOOT/bootx64.efi 新，打印过期提醒
 2026-10-14 13:11:47 +08:00
TermiNexus d093d3fc8b chore: 改名同步 TransPyV -> ViperC（源码/配置内的纯替换） 2026-10-12 15:06:50 +08:00
TermiNexus cd1cc915c5 修正了build.py，重置基线 2026-09-11 10:34:34 +08:00
TermiNexus b887d3d9c2 更新，部分功能可用 2026-08-27 09:47:47 +08:00
TermiNexus 56d127cb88 将 project.json 改为了 project.vpj，初步尝试了使用 Viper 插件高亮 2026-07-30 17:24:35 +08:00
Viper 6813947181 Initial import of ViperOS 2026-07-19 12:38:20 +08:00