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: Chris Metcalf
Subject: Re: [Qemu-devel] [PATCH] tile: Can load elf64 tilegx binary successfully for linux-user.
Date: Wed, 11 Feb 2015 19:24:50 -0500
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

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.

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.

+#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.

@@ -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.

+        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.

+++ 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
+
+/* 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.

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.

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.

--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com




reply via email to

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