Hello!
FALRU (src/mem/cache/tags/fa_lru.*) has segmentation faults in the current 
simulator state. In an attempt to solve them, I've made two patches. The second 
one (https://gem5-review.googlesource.com/c/public/gem5/+/8882), however, 
evidences a symbol lookup error on my machine (gcc version 5.4.0 20160609 
(Ubuntu 5.4.0-6ubuntu1~16.04.9)). 

I'm using ./configs/example/se.py with the test program I proposed 
(https://gem5-review.googlesource.com/c/public/gem5/+/9022) (although it 
happened with every test program bigger than hello I tried. I've also tried 
with threads.cpp, but another error showed up: "panic: Tried to read unmapped 
address".), and the following error is generated (depends directly on the 
program being used, but they are always regarding libstdc++.so.6):

    symbol lookup error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: undefined 
symbol: _ZNKSt9type_info11__do_upcastEPKN10__cxxabiv117__class_type_infoEPPv, 
version GLIBCXX_3.4

Checking nm's output, I notice the symbol is there

    nm -D /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep 
_ZNKSt9type_info11__do_upcastEPKN10__cxxabiv117__class_type_infoEPPv
    000000000008e4d0 T 
_ZNKSt9type_info11__do_upcastEPKN10__cxxabiv117__class_type_infoEPPv

Then, checking ldd:

    ldd build/X86/gem5.opt
    linux-vdso.so.1 =>  (0x00007fff8b5d9000)
    libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 
(0x00007fe4b4534000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x00007fe4b4317000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe4b40fd000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe4b3ef5000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x00007fe4b3b73000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe4b386a000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe4b3654000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe4b328a000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe4b3086000)
    libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fe4b2e83000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fe4b4ac2000)

And as can be seen, libstdc++ is being chosen correctly.
I'd like to know if the same happens to anyone else, and if so would anyone 
happen to know a solution?

Regards,Daniel Carvalho
_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to