Hello Jason, On 17-01-27 23:01:44, Jason Lowe-Power wrote: > Hi Sanchayan, > > Can you test this patch to see if it fixes your issue? If so, hit "ship it" > on reviewboard for me :). You can download the patch. Then apply it with > "hg qimport <filename> && hg qpush". I think there may be a couple of other > patches up there to get Arch Linux support working better that you can > test, too ;). > > http://reviews.gem5.org/r/3793/
Thanks for the fix. I just tested it and it works. As requested, I shipped it. Sure I will try and take a look if I can help testing the ones I can identify and reproduce. Regards, Sanchayan. > > Cheers, > Jason > > On Mon, Jan 23, 2017 at 9:34 AM Jason Lowe-Power <[email protected]> > wrote: > > > Hi Sanchayan, > > > > gem5 does have support for dynamic executables on Linux x86 platforms. I'm > > not certain what the limitations are, but there is some support for it. > > > > I still don't know why you're experiencing that error with your regular > > binary. Maybe we can take this off-list and you can send me the binary and > > I'll try it out on my gem5. > > > > Have you tried any other binaries and seen a similar error? > > > > Cheers, > > Jason > > > > On Fri, Jan 20, 2017 at 11:10 AM <[email protected]> wrote: > > > > Hello Jason, > > > > On 17-01-20 15:33:23, Jason Lowe-Power wrote: > > > Hi Sanchayan, > > > > > > I'm still not sure what's going wrong when executing your binary. It > > seems > > > that the problem is that the code is calling a function that doesn't > > exist. > > > The instruction pointer is updated to an invalid address in the call > > > instruction. > > > > > > Have you run ldd on the binary to make sure that there's nothing that is > > > dynamically linked? > > > > > > > Yes I had checked with ldd and file earlier to make sure. > > > > file hello > > hello: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), > > statically linked, for GNU/Linux 2.6.32, > > BuildID[sha1]=e990c89ba084cc73939408c94f5d500e23fc5e1a, not stripped > > > > ldd hello > > not a dynamic executable > > > > > I just tested the hello.c file in tests/test-progs/hello/src with gcc 6.3 > > > and I didn't see any error running the resulting binary in with the > > current > > > gem5 head. Did you make changes to this file? Maybe you could add your > > > changes in one at a time on top of this file to find out what is causing > > > the issue. > > > > > > > Did not make any changes to the source code except to make gem5 build on > > Arch > > Linux with this change > > > > https://github.com/SanchayanMaity/gem5/commit/c005da6779ff72456062fa35b73e48aeafc77c29 > > > > The hello world code I am trying to use is out of gem5 source tree and is > > the same > > as the one included in the source tree. > > > > I rechecked again as to what "file" gives for the pre compiled binary and > > the binary > > I get from my compilation. > > > > For the precompiled binary > > tests/test-progs/hello/bin/x86/linux/hello: ELF 64-bit LSB executable, > > x86-64, version 1 (SYSV), statically linked, > > for GNU/Linux 2.4.1, not stripped > > > > Using this to compile > > gcc -static hello.c -O2 -o hello -lm > > > > gives > > > > hello: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), > > statically linked, for GNU/Linux 2.6.32, > > BuildID[sha1]=ec77c0af06f0e4ebc016fb6647fbbc40c0f93dca, not stripped > > > > and using this to compile > > gcc -static-libgcc hello.c -O2 -o hello -lm > > > > gives > > > > hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically > > linked, interpreter > > /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, > > BuildID[sha1]=6560ccd5b10f94e3ac18408e8463f01e78dce5b4, not > > stripped > > > > ldd hello > > linux-vdso.so.1 (0x00007ffed0971000) > > libm.so.6 => /usr/lib/libm.so.6 (0x00007f17c0cad000) > > libc.so.6 => /usr/lib/libc.so.6 (0x00007f17c090f000) > > /lib64/ld-linux-x86-64.so.2 (0x00007f17c0fb1000) > > > > This one above seems to work even though it says dynamically linked!!!! > > > > gem5 Simulator System. http://gem5.org > > gem5 is copyrighted software; use the --copyright option for details. > > > > gem5 compiled Jan 19 2017 17:36:17 > > gem5 started Jan 20 2017 22:15:05 > > gem5 executing on Sanchayan-Arch, pid 5830 > > command line: build/X86/gem5.opt configs/learning_gem5/part1/two_level.py > > /home/sanchayan/IIT/CS570/hello > > > > Global frequency set at 1000000000000 ticks per second > > warn: DRAM device capacity (8192 Mbytes) does not match the address range > > assigned (512 Mbytes) > > 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 > > warn: ClockedObject: More than one power state change request encountered > > within the same simulation tick > > Beginning simulation! > > info: Entering event queue @ 0. Starting simulation... > > warn: ignoring syscall access(140737352013760, ...) > > warn: ignoring syscall mprotect(140737349545984, ...) > > warn: ignoring syscall mprotect(140737346351104, ...) > > warn: ignoring syscall mprotect(140737348444160, ...) > > warn: ignoring syscall mprotect(140737351639040, ...) > > warn: ignoring syscall mprotect(6291456, ...) > > warn: ignoring syscall mprotect(140737354121216, ...) > > Hello world! > > Exiting @ tick 909049000 because target called exit() > > > > I am surprised frankly as to why this happens since I thought gem5 can't > > run > > a dynamically linked executable. > > > > Regards, > > Sanchayan. > > > > > Cheers, > > > Jason > > > > > > On Thu, Jan 19, 2017 at 1:19 PM <[email protected]> wrote: > > > > > > > Hello Jason, > > > > > > > > On 17-01-19 15:24:18, Jason Lowe-Power wrote: > > > > > Hi Sanchayan, > > > > > > > > > > I'm not sure what the problem is when you're running hello. I believe > > > > > you've compiled it correctly. The error indicates that the > > application is > > > > > trying to read an address that was never allocated. > > > > > To figure out the issue, I would follow these steps: > > > > > 1. Make sure the binary executes correctly on the native system > > > > > > > > Yes it does execute correctly on native system. > > > > > > > > > 2. Using some debug flags to try to track down the issue. I would > > start > > > > > with SyscallBase and then SyscallVerbose (or SyscallAll which is > > compound > > > > > debug flag including both of these). > > > > > > > > The log is here using the debug flags you mentioned. > > > > http://pastebin.com/7KxGsyHP > > > > > > > > > 3. Figuring out exactly which instructions and where in the source is > > > > > causing the issue. For this, you may have to use the Exec debug flag > > then > > > > > trace it back to the code with objdump. > > > > > > > > Just the assembler part of the code section > > > > > > > > 0000000000400990 <_start>: > > > > 400990: 31 ed xor %ebp,%ebp > > > > 400992: 49 89 d1 mov %rdx,%r9 > > > > 400995: 5e pop %rsi > > > > 400996: 48 89 e2 mov %rsp,%rdx > > > > 400999: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp > > > > 40099d: 50 push %rax > > > > 40099e: 54 push %rsp > > > > 40099f: 49 c7 c0 60 15 40 00 mov $0x401560,%r8 > > > > 4009a6: 48 c7 c1 d0 14 40 00 mov $0x4014d0,%rcx > > > > 4009ad: 48 c7 c7 ae 0a 40 00 mov $0x400aae,%rdi > > > > 4009b4: 67 e8 d6 04 00 00 addr32 callq 400e90 > > > > <__libc_start_main> > > > > 4009ba: f4 hlt > > > > 4009bb: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) > > > > > > > > Not an expert on assembly code but cross checking against the output > > > > using debug flags do I interpret correctly that it failed at nopl > > > > instruction? > > > > > > > > Looking at what NOPL does on below link > > > > > > http://stackoverflow.com/questions/12559475/what-does-nopl-do-in-x86-system > > > > > > > > is it that NOPL incrementing IP/EIP made it point to a section of > > > > memory not mapped for code or something? Sorry if this is a completely > > > > stupid intepretation. > > > > > > > > > > > > > > It's probably something simple, but it's hard to tell just by the > > error > > > > > message what the problem is. Let us know if you can't figure it out > > with > > > > > the above suggestions. > > > > > > > > > > For the protobuf compile error: gem5 is very sensitive to external > > > > > dependencies. If you've updated one of the dependencies, I would try > > > > > recompiling gem5 from scratch (e.g., deleting the build/ directory > > and > > > > > recompiling). > > > > > > > > I guessed correctly. Removing the build and recompiling worked. > > > > > > > > > > > > > > Containers may be helpful in this situation. I've played around with > > > > > containers and with docker, specifically, some, but I haven't > > developed a > > > > > reasonable workflow for myself, yet. You can search around on > > dockerhub > > > > for > > > > > some example gem5 dockerfiles written by me and others. > > > > > > > > I have used containers for OpenEmbedded before and also saw your post > > at > > > > http://www.lowepower.com/jason/setting-up-a-gem5-container.html > > > > > > > > so asked if it would be recommended. Thanks for the book and blog > > entries. > > > > Will go for a container when it breaks with the next protobuf update. > > > > > > > > - Sanchayan. > > > > > > > > > > > > > > Cheers, > > > > > Jason > > > > > > > > > > On Thu, Jan 19, 2017 at 5:23 AM <[email protected]> wrote: > > > > > > > > > > > Hello, > > > > > > > > > > > > I am using gem5 compiled from source with the last commit at > > > > > > > > > > > > commit 1738a7d2601ba757ae6ab36f0549a50396d73e45 > > > > > > Author: Andreas Sandberg <[email protected]> > > > > > > Date: Tue Jan 3 17:31:39 2017 +0000 > > > > > > > > > > > > sim: Remove declaration of unused CountedDrainEvent > > > > > > > > > > > > on Arch Linux with gcc 6.3.1. > > > > > > > > > > > > Am trying to use a hello world program compiled externally as > > follows > > > > > > > > > > > > gcc -static hello.c -O2 -o hello -lm > > > > > > > > > > > > file hello > > > > > > hello: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), > > > > > > statically linked, > > > > > > for GNU/Linux 2.6.32, > > > > > > BuildID[sha1]=85a8107f82fcc766f604b2e015d130c8dfd07490, not > > > > > > stripped > > > > > > > > > > > > Trying to run a syscall emulation as below > > > > > > build/X86/gem5.opt configs/learning_gem5/part1/two_level.py > > > > > > /home/sanchayan/gemapp/hello > > > > > > > > > > > > results in a stack trace. > > > > > > > > > > > > gem5 Simulator System. http://gem5.org > > > > > > gem5 is copyrighted software; use the --copyright option for > > details. > > > > > > > > > > > > gem5 compiled Jan 18 2017 17:20:15 > > > > > > gem5 started Jan 19 2017 15:52:58 > > > > > > gem5 executing on Sanchayan-Arch, pid 16357 > > > > > > command line: build/X86/gem5.opt > > > > configs/learning_gem5/part1/two_level.py > > > > > > /home/sanchayan/IIT/CS570/hello > > > > > > > > > > > > Global frequency set at 1000000000000 ticks per second > > > > > > warn: DRAM device capacity (8192 Mbytes) does not match the address > > > > range > > > > > > assigned (512 Mbytes) > > > > > > 0: system.remote_gdb.listener: listening for remote gdb #0 on port > > 7000 > > > > > > warn: ClockedObject: More than one power state change request > > > > encountered > > > > > > within the same simulation tick > > > > > > Beginning simulation! > > > > > > info: Entering event queue @ 0. Starting simulation... > > > > > > panic: Tried to write unmapped address 0xffffee28. > > > > > > @ tick 450000 > > > > > > [invoke:build/X86/arch/x86/faults.cc, line 163] > > > > > > Memory Usage: 681232 KBytes > > > > > > Program aborted at tick 450000 > > > > > > > > > > > > The same if compiled for ARM works. I guess it's something to do > > with > > > > > > AddrRange specified to system.mem_ranges > > > > > > somehow and the memory mapping for ARM and x86 being different? > > > > > > > > > > > > Also how sensitive is gem5 to external dependencies?. Just updated > > the > > > > > > system and protobuf was updated > > > > > > but in the process gem5 stopped working. > > > > > > > > > > > > build/X86/gem5.opt: error while loading shared libraries: > > > > > > libprotobuf.so.10: cannot open shared object file: No such file or > > > > directory > > > > > > > > > > > > Does the gem5 community recommend containers or such when using > > rolling > > > > > > release distros? > > > > > > > > > > > > Thanks & Regards, > > > > > > Sanchayan. > > > > > > _______________________________________________ > > > > > > gem5-users mailing list > > > > > > [email protected] > > > > > > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > > > > > > > -- > > > > > > > > > > Jason > > > > > > > > > _______________________________________________ > > > > > gem5-users mailing list > > > > > [email protected] > > > > > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > > > > > -- > > > > > > Jason > > > > -- > > > > Jason > > _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
