[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] tile: Can load elf64 tilegx binary successfully
From: |
Chen Gang S |
Subject: |
Re: [Qemu-devel] [PATCH] tile: Can load elf64 tilegx binary successfully for linux-user. |
Date: |
Thu, 12 Feb 2015 11:32:23 +0800 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
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
- [Qemu-devel] [PATCH] tile: Can load elf64 tilegx binary successfully for linux-user., Chen Gang S, 2015/02/11
- Re: [Qemu-devel] [PATCH] tile: Can load elf64 tilegx binary successfully for linux-user., Chen Gang S, 2015/02/11
- Re: [Qemu-devel] [PATCH] tile: Can load elf64 tilegx binary successfully for linux-user., Chris Metcalf, 2015/02/12
- Re: [Qemu-devel] [PATCH] tile: Can load elf64 tilegx binary successfully for linux-user., Chen Gang S, 2015/02/12
- Re: [Qemu-devel] [PATCH] tile: Can load elf64 tilegx binary successfully for linux-user., Peter Maydell, 2015/02/12
- Re: [Qemu-devel] [PATCH] tile: Can load elf64 tilegx binary successfully for linux-user., Chen Gang S, 2015/02/13
- Re: [Qemu-devel] [PATCH] tile: Can load elf64 tilegx binary successfully for linux-user., Peter Maydell, 2015/02/13
- Re: [Qemu-devel] [PATCH] tile: Can load elf64 tilegx binary successfully for linux-user., Chen Gang S, 2015/02/13
Re: [Qemu-devel] [PATCH] tile: Can load elf64 tilegx binary successfully for linux-user., Peter Maydell, 2015/02/11