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
