date:20220214

[gem5-users] Doubt on the ARM exec trace results when compared with disassembly of the executable

2022-02-14 Thread tom jose via gem5-users

 Hi,
I tried running a simple hello world on ARM and went through the "exec"
debug trace. I also used the disassembly of the executable to compare the
sequence and register values. While doing so,i came across two doubts:
1. On the instruction "adds" being used instead of "cmn" but "xzr" not
mentioned in the trace
2. Does svc instruction update x0 register? If so, how is the value stored
in x0 determined? Can i know it from the disassembly of the executable or
will i need to know about the code executed in the kernel as a result of
svc syscall?

Details described below:

5896098: system.cpu_cluster.cpus: T0 : 0x421324 @_dl_discover_osversion+4
 :   add   x0, sp, #120   : IntAlu :  D=0x007efb58
...

6007986: system.cpu_cluster.cpus: T0 : 0x439b40 @__uname:   movz   x8,
#160, #0  : IntAlu :  D=0x00a0
6007986: system.cpu_cluster.cpus: T0 : 0x439b44 @__uname+4:   svc   #0x0
  : IntAlu :
6064596: system.cpu_cluster.cpus: T0 : 0x439b48 @__uname+8:   adds
x0, #4095 : IntAlu :  D=0x
6064929: system.cpu_cluster.cpus: T0 : 0x439b4c @__uname+12:   b.cs
<__uname+20>  : IntAlu :
6064929: system.cpu_cluster.cpus: T0 : 0x439b50 @__uname+16:   ret
 : IntAlu :
6065928: system.cpu_cluster.cpus: T0 : 0x421334 @_dl_discover_osversion+20
   :   add   x3, sp, #250   : IntAlu :  D=0x007efbda
6065928: system.cpu_cluster.cpus: T0 : 0x421338 @_dl_discover_osversion+24
   :   cbnz   w0, <_dl_discover_osversion+184> : IntAlu :
6066261: system.cpu_cluster.cpus: T0 : 0x42133c @_dl_discover_osversion+28
   :   movz   w6, #0, #0: IntAlu :  D=0x
6066594: system.cpu_cluster.cpus: T0 : 0x421340 @_dl_discover_osversion+32
   :   movz   w0, #0, #0: IntAlu :  D=0x

On doing the disassembly on the executable, we could see the following :
00439b40 <__uname>:
  439b40: d2801408 mov x8, #0xa0   // #160
  439b44: d401 svc #0x0
  439b48: b13ffc1f cmn x0, #0xfff
  439b4c: 5442 b.cs 439b54 <__uname+0x14>  // b.hs, b.nlast
  439b50: d65f03c0 ret

Doubt : in GEM5, " cmn x0, #0xfff "  is treated as adds instead of cmn. But
from the ARM isa document, cmn is identical to "adds xzr, Xn, #imm". So is
the GEM5 internally following this format with xzr? or does GEM5 update x0
here as the trace doesnt show xzr?

Disassembly on the executable:
00421320 <_dl_discover_osversion>:
  421320: d10803ff sub sp, sp, #0x200
  421324: 9101e3e0 add x0, sp, #0x78
  421328: a9007bfd stp x29, x30, [sp]
  42132c: 910003fd mov x29, sp
  421330: 94006204 bl 439b40 <__uname>
  421334: 9103ebe3 add x3, sp, #0xfa
  421338: 35000500 cbnz w0, 4213d8 <_dl_discover_osversion+0xb8>
  42133c: 5286 mov w6, #0x0   // #0
  421340: 5280 mov w0, #0x0   // #0

since the cbnz didnt take a branch, it means lower 32 bits of x0 (or w0
register) is having a value 0.

So i tried looking through the ARM document on svc implementation:
https://developer.arm.com/documentation/ddi0487/latest In page number 1957,
description and operation for svc is described. There was no mention on x0
being updated with the syscall return value. But i could see in few other
websites:

https://cit.dixie.edu/cs/2810/arm64-assembly.html

https://azeria-labs.com/writing-arm-shellcode/

that [x0] or [register 0] is updated with the return value.


So could you please provide more insight on how the stored value on x0 is
calculated? Any suggestions would be helpful.

Thanks in advance.
Regards,
Tom



___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: riscv-ubuntu 20.04 FS mode

2022-02-14 Thread Bobby Bruce via gem5-users

Hey Nikos,

I'm not sure I know exactly how to remove all these annoying systemd
services. Currently Hoa is assigned this task:
https://gem5.atlassian.net/browse/GEM5-1177

@Hoa can you make this a top priority for you? I think 6+ hours for a boot
is a bit too much. I'm sure there must be a way to modify this disk image
to make it faster.

To answer your second question, this should work:

```

image = CustomDiskImageResource(
local_path = "path/to/your/disk/image/here",
disk_root_partition = "1", # This is the partition in the disk image to
use. 'None' if there is no disk image
)

board.set_kernel_disk_workload(
kernel = Resource("riscv-bootloader-vmlinux-5.10"),
disk_image = image,
)

```



Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Sat, Feb 12, 2022 at 7:19 AM Νικόλαος Ταμπουρατζής via gem5-users <
gem5-users@gem5.org> wrote:

> Dear all,
>
> I have successfully emulated the riscv-ubuntu.img through qemu! The
> problem was that I use Ubuntu 20.04 and it requires the Hirsute’s
> version of u-boot-qemu (wget
>
> http://mirrors.kernel.org/ubuntu/pool/main/u/u-boot/u-boot-qemu_2021.01+dfsg-3ubuntu9_all.deb)
> and not the standard through the apt
> install.
>
> Now I have two questions:
>
> 1) How can I disable the huge number of services in order to speedup
> the gem5 boot process through qemu?
>
> 2) When I execute the following: "./build/RISCV/gem5.opt
> configs/example/gem5_library/riscv-ubuntu-run.py", it downloads
> automatically the riscv-ubuntu-20.04-img. How can I set another image?
> The --disk-image option is not working.
>
>
> Thank you in advance!!!
> Best regards,
> Nikos
>
>
> Quoting Νικόλαος Ταμπουρατζής via gem5-users :
>
> > Dear Hoa,
> >
> > Thank you very much for your information! I try to emulate the
> > ubuntu-image through qemu (following this tutorial:
> > http://resources.gem5.org/resources/riscv-ubuntu) and I get the
> > following TFTP error:
> >
> > I appreciate any help!!
> >
> > Best regards,
> > Nikos
> >
> >
> > cossim@cossim-virtual-machine:~/riscv-ubuntu$
> > ./qemu/build/qemu-system-riscv64 -machine virt -nographic \
> >> -m 16384 -smp 8 \
> >> -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf \
> >> -kernel /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf \
> >> -device virtio-net-device,netdev=eth0 \
> >> -netdev user,id=eth0,hostfwd=tcp::-:22 \
> >> -drive file=ubuntu.img,format=raw,if=virtio
> >
> > OpenSBI v0.9
> >_  _
> >   / __ \  / |  _ \_   _|
> >  | |  | |_ __   ___ _ __ | (___ | |_) || |
> >  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
> >  | |__| | |_) |  __/ | | |) | |_) || |_
> >   \/| .__/ \___|_| |_|_/|/_|
> > | |
> > |_|
> >
> > Platform Name : riscv-virtio,qemu
> > Platform Features : timer,mfdeleg
> > Platform HART Count   : 8
> > Firmware Base : 0x8000
> > Firmware Size : 156 KB
> > Runtime SBI Version   : 0.2
> >
> > Domain0 Name  : root
> > Domain0 Boot HART : 5
> > Domain0 HARTs : 0*,1*,2*,3*,4*,5*,6*,7*
> > Domain0 Region00  : 0x8000-0x8003 ()
> > Domain0 Region01  : 0x-0x (R,W,X)
> > Domain0 Next Address  : 0x8020
> > Domain0 Next Arg1 : 0x8220
> > Domain0 Next Mode : S-mode
> > Domain0 SysReset  : yes
> >
> > Boot HART ID  : 5
> > Boot HART Domain  : root
> > Boot HART ISA : rv64imafdcsu
> > Boot HART Features: scounteren,mcounteren,time
> > Boot HART PMP Count   : 16
> > Boot HART PMP Granularity : 4
> > Boot HART PMP Address Bits: 54
> > Boot HART MHPM Count  : 0
> > Boot HART MHPM Count  : 0
> > Boot HART MIDELEG : 0x0222
> > Boot HART MEDELEG : 0xb109
> >
> >
> > U-Boot 2021.01+dfsg-3ubuntu0~20.04.4 (Sep 21 2021 - 15:55:38 +)
> >
> > CPU:   rv64imafdcsu
> > Model: riscv-virtio,qemu
> > DRAM:  16 GiB
> > In:uart@1000
> > Out:   uart@1000
> > Err:   uart@1000
> > Net:   eth0: virtio-net#0
> > Hit any key to stop autoboot:  0
> >
> > Device 0: 1af4 VirtIO Block Device
> > Type: Hard Disk
> > Capacity: 13824.0 MB = 13.5 GB (28311552 x 512)
> > ... is now current device
> > Scanning virtio 0:1...
> > Found /boot/extlinux/extlinux.conf
> > Retrieving file: /boot/extlinux/extlinux.conf
> > 755 bytes read in 4 ms (183.6 KiB/s)
> > U-Boot menu
> > 1:Ubuntu 20.04.3 LTS 5.11.0-1017-generic
> > 2:Ubuntu 20.04.3 LTS 5.11.0-1017-generic (rescue target)
> > Enter choice: 1:  Ubuntu 20.04.3 LTS 5.11.0-1017-generic
> > Retrieving file: /boot/initrd.img-5.11.0-1017-generic
> > 170008555 bytes read in 728 ms (222.7 MiB/s)
> > Retrieving file: /boot/vmlinuz-5.11.0-1017-generic
> > 25258496 bytes read in

[gem5-users] Doubt on the ARM exec trace results when compared with disassembly of the executable

[gem5-users] Re: riscv-ubuntu 20.04 FS mode

2 matches

Site Navigation

Mail list logo

Footer information