qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]