一连搞了搞几天，总结下

24 Apr 2022

现在工具链可以跑通了。 OpenSPARC T1编译的是1c1t，也就是一核单线程的，所以obp_rom用的也要是1c1t的。但Solaris的包进系统后没有启动起来，Ubuntu的进系统了。

u@unamed:~/prjs/testaceos$ source ~/Xilinx/10.1/ISE/settings64.sh 
u@unamed:~/prjs/testaceos$ source ~/Xilinx/10.1/EDK/settings64.sh 

u@unamed:~/prjs/testaceos$ xmd -tcl genace.tcl -jprog -target mdm -board ml505 -hw ~/prjs/OpenSPARCT1/design/sys/edk/implementation/system.bit -elf executable.elf -data ./1c1t_obp_prom.bin 0x8ff00000 -data ./ramdisk.ubuntu-7.10-gutsy.gz 0x8af00000 -ace uty_testubuntu_patchbitgen1c1t.ace

感觉有可能是编译core的时候没有选4t，结果操作系统boot的时候有问题？

因为OpenSPARC大概是08年左右开源出来的，所以工具链都是那时候的Solaris和Ubuntu，所以之前的几天遇到很多坑。特别是Java的问题。

用于sythesis的编译器xst是Xiline ISE9.1，而EDK用的是10.1.3。更新版本的EDK能装，但有问题，启动的时候好像很多东西没启动，打不开xmp文件。

还有就是bitgen了。

用笨方法，通过查找出错信息的字符串，定位了这个lib。 /home/u/Xilinx/10.1/ISE/virtex5/lib/lin64/libBsRain_Bitgen.so

gdb

step out finish

改内存

(gdb) set {char}0x00007ff275600d25=0x90
(gdb) set {int}0x00007ff275600d21=0x90909090

列出shared library。

(gdb) info sharedlibrary 
From                To                  Syms Read   Shared Object Library
0x00007ff27cc16850  0x00007ff27cc41978  Yes (*)     /home/u/Xilinx/10.1/ISE/lib/lin64/libBs_Bitgen.so
0x00007ff27ca6bec0  0x00007ff27cadbd08  Yes (*)     /home/u/Xilinx/10.1/ISE/lib/lin64/libXCad_HDHelpers.so
0x00007ff27c8ee780  0x00007ff27c936a68  Yes (*)     /home/u/Xilinx/10.1/ISE/lib/lin64/libPersonalityModule.so
0x00007ff27c7ad6d0  0x00007ff27c7be6f8  Yes (*)     /home/u/Xilinx/10.1/ISE/lib/lin64/libPrjrep_Clientac.so
0x00007ff27c669a80  0x00007ff27c689058  Yes (*)     /home/u/Xilinx/10.1/ISE/lib/lin64/libUtilities.so
0x00007ff27c4926f0  0x00007ff27c517b18  Yes (*)     /home/u/Xilinx/10.1/ISE/lib/lin64/libPortability.so
0x00007ff27c315660  0x00007ff27c3317b8  Yes (*)     /home/u/Xilinx/10.1/ISE/lib/lin64/libBs_Bitstream.so
0x00007ff27c0ad930  0x00007ff27c0da498  Yes (*)     /home/u/Xilinx/10.1/ISE/lib/lin64/libData2MEMDesignUtil.so

列出所有函数 info fucntions

列函数后面还可以带正则表达式。

(gdb) info functions \w*plladv\w*
All functions matching regular expression "\w*plladv\w*":

Non-debugging symbols:
0x00007ff2755f90a8  BsRain_BfdTile::plladvpminfo(Bs_BfdCell*, char const*, char const*, char const*, char const*)@plt
0x00007ff275600b00  BsRain_BfdTile::plladvpminfo(Bs_BfdCell*, char const*, char const*, char const*, char const*)

地址上下断点

(gdb) break *0x00007ff275600cf9
Breakpoint 2 at 0x7ff275600cf9

单步的时候显示汇编指令

(gdb) set disassemble-next-line on

vi xxd

:%!xxd

To save it

:%!xxd -r > new-filename

x86-64 calling convention

Here is a quick overview of common calling conventions. Note that the calling conventions are usually more complex than represented here (for instance, how is a large struct returned? How about a struct that fits in two registers? How about va_list’s?). Look up the specifications if you want to be certain. It may be useful to write a test function and use gcc -S to see how the compiler generates code, which may give a hint of how the calling convention specification should be interpreted.

x86_64_calling_convention

Note 1: The called function is allowed to modify the arguments on the stack and the caller must not assume the stack parameters are preserved. The caller should clean up the stack.

Note 2: There is a 128 byte area below the stack called the ‘red zone’, which may be used by leaf functions without increasing %rsp. This requires the kernel to increase %rsp by an additional 128 bytes upon signals in user-space. This is not done by the CPU - if interrupts use the current stack (as with kernel code), and the red zone is enabled (default), then interrupts will silently corrupt the stack. Always pass -mno-red-zone to kernel code (even support libraries such as libc’s embedded in the kernel) if interrupts don’t respect the red zone.

Note 3: Stack is 16 byte aligned at time of call. The call pushes %rip, so the stack is 16-byte aligned again if the callee pushes %rbp.

Note 4: Stack is 8 byte aligned at all times outside of prologue/epilogue of function.

u@home:~$

Archive

About

RSS