See http://gem5.org/wiki/images/8/80/2015_ws_07_pthread.pdf. There is some support, but I wouldn't expect everything to work perfectly.
Jason On Tue, Feb 21, 2017, 9:46 AM 681687 <[email protected]> wrote: > Hi, > > I thought I couldn't use dynamic link in Syscall Emulation mode. > > Could you provide me some documentation about how to use dynamic link in > SE with X86? > > Thank you very much. > > Regards, > > Alberto. > > > El 2017-02-21 16:17, Jason Lowe-Power escribió: > > Hi Alberto, > > > > m5threads is not a perfect implementation of pthreads. Since m5threads > > doesn't use the futex system call, there are a number of cases where > > it won't behave the same way as pthreads. I've specifically run into a > > problem using pthread barrier where I had to re-write my code to use > > sense barriers because of a problem in m5threads. > > > > Unfortunately, I don't have any simple suggestions to fix this. You > > could dig into the m5threads code to see if you could fix the problem > > there. > > > > Another option is to use x86 and native pthreads. gem5 has support for > > using dynamically linked binaries on x86. This might solve your > > problem. > > > > Cheers, > > Jason > > > > On Mon, Feb 20, 2017 at 6:34 PM 681687 <[email protected]> wrote: > > > >> Hi, > >> > >> I am trying to simulate a benchmark developed using OpenCV 3.1 in > >> Syscall emulation mode. > >> > >> OpenCV uses libpthread due to the use of locks, so I have to use > >> "m5threads" istead "libpthread" because Syscall emulatio mode can't > >> emulate the libpthread calls. > >> > >> I can't use Full System mode because I am using gem5 with Aladdin, > >> and > >> Aladdin doesn't support Full System mode. > >> > >> Using "m5threads" instead of "libpthread" produces a deadlock when > >> I try > >> to read an image with the OpenCV function "imread(path-to-the > >> image)". > >> > >> Compiling in DEBUG mode I obtain the next trace before the > >> deadlock: > >> > >> pthread_mutex_lock: start > >> pthread_mutex_lock: 11462 > >> pthread_mutex_lock: start > >> pthread_mutex_lock: 11462 > >> > >> The process is calling 2 consecutive times to the mutex_lock > >> function. > >> > >> I'm thinking that the driver should be able to access the lock, but > >> it > >> is not capable or is calling another function that is not the > >> "m5threads" "unlock" function, but I really do not know what's > >> going on > >> and how can I fix it. > >> > >> Thank you very much. > >> > >> Best regards, > >> > >> Alberto Alvarez. > >> _______________________________________________ > >> gem5-users mailing list > >> [email protected] > >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [1] > > > > > > Links: > > ------ > > [1] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > _______________________________________________ > > gem5-users mailing list > > [email protected] > > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
