On 2/12/15 08:24, Chris Metcalf wrote: > On 2/12/15 08:00, Chen Gang S wrote: >> After load elf64 tilegx binary for linux-user, the working flow reaches >> the first correct instruction postion "__start". > > Congratulations on getting started. I hope you have success with the > emulation part. >
Thank you very much for your encourage! :-) >> index f185dd0..d9e0dec 100755 >> --- a/configure >> +++ b/configure >> @@ -5089,6 +5089,9 @@ case "$target_name" in >> TARGET_BASE_ARCH=mips >> echo "TARGET_ABI_MIPSN64=y" >> $config_target_mak >> ;; >> + tile) >> + TARGET_ARCH=tile >> + ;; > > I would recommend using "tilegx" here and throughout since in principle > "tile" includes both the old 32-bit tilepro architecture as well as the newer > 64-bit tilegx architecture. > OK, I shall use tilegx. >> +#define EM_TILE 191 /* Tile */ >> +#define EM_TILE_OLD 0x2597 /* Tile compat */ > > No need for EM_TILE_OLD - it never really got out into the wild. > > Also, 191 is EM_TILEGX in <elf.h>, so you really should use the same name > here, not EM_TILE. > OK, I shall use EM_TILEGX directly, also remove EM_TILE_OLD and all related code. >> @@ -2012,6 +2035,7 @@ static void load_elf_interp(const char *filename, >> struct image_info *info, >> } >> load_elf_image(filename, fd, info, NULL, bprm_buf); >> + >> return; >> exit_perror: > > Stray newline - you should proof read the diff to avoid stuff like this. > OK, thanks. I shall notice about it, next time. >> + env->regs[56] = regs->sn; >> + env->regs[57] = regs->idn0; >> + env->regs[58] = regs->idn1; >> + env->regs[59] = regs->udn0; >> + env->regs[60] = regs->udn1; >> + env->regs[61] = regs->udn2; >> + env->regs[62] = regs->udn3; >> + env->regs[63] = regs->zero; > > Registers from 56 to 63 aren't really worth emulating. 56 to 62 aren't real > registers; they're just access to the on-chip networks. If you were to really > emulate them for multichip support, you'd need a bunch of special support to > understand message formats and header words and wormhole routing, etc, which > is probably out of scope. Just ignoring them completely is probably safest > for now. And 63 just always reads as zero and discards writes. > OK, thanks. I shall remove them. >> +++ b/linux-user/tile/syscall_nr.h >> @@ -0,0 +1,327 @@ >> +#ifndef TILE_SYSCALL_NR >> +#define TILE_SYSCALL_NR >> + >> +/* >> + * Copy from linux kernel asm-generic/unistd.h, which tile uses. >> + * >> + * At present, do not support 32-bit (-m32) tilegx executable binary >> + */ >> +#define TARGET_NR_io_setup 0 >> +#define TARGET_NR_io_destroy 1 >> +#define TARGET_NR_io_submit 2 > [...] > > Isn't there a way to say "use the asm-generic syscalls"? What does ARM64 do, > for example? They use the generic syscall list. > >> [...] >> +#define TARGET_NR_bpf 280 >> +#define TARGET_NR_execveat 281 >> + Do you mean we need to remove them? >> +/* current tilegx Linux kernel do not want to support the macros below */ >> + > > Probably better not to define them, then look at fixing anything that breaks > as a result. Again, ARM64 will be the same. > Do you mean we do not need to define the macros below? #define TARGET_NR_open 1024 #define TARGET_NR_link 1025 #define TARGET_NR_unlink 1026 #define TARGET_NR_mknod 1027 #define TARGET_NR_chmod 1028 #define TARGET_NR_chown 1029 ... And excuse me, my English is not quite well, I don't quite understand: "fixing anything that breaks as a result". Could you provide more details? Thanks. > Similar comments apply to the other headers that tile uses that are just > asm-generic versions. It probably makes sense to have a qemu framework for > asm-generic as well. > What you said above sounds reasonable to me, but I guess, I am not the suitable member to do it, at present. > Tilera did some work on a qemu port only intended to be used with KVM for > virtualization, so it probably doesn't do you much good. If you're > interested, I can send you the diffs. > Welcome the related diffs, I guess, it must be helpful. :-) Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
