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
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to