Hi Guru,

I was running the simulation keeping the disk image mounted. I think that
might have caused the issue. I have unmounted the disk image anf also
decreased the number of iterations executed by the program and it seems to
work as of now. Thanks for your help.


Regards
Rahul

On Sat, Dec 27, 2014 at 2:25 PM, Guru Prasad <[email protected]> wrote:

> Ah, I seem to have misunderstood regarding x86 simulations.
>
> Okay, first, I'm pretty sure that you cannot run a gcc which was compiled
> with --target x86* on an ARM machine.
> I had to cross-compile gdb and put the binary into the image file to use
> it from within the simulation. This is what you would have to do if you
> want to debug a userspace program in Gem5 - run gdb from within the
> simulation (from m5term).
>
> If you're running a full ubuntu image, you may want to try running 'file
> gcc' to get more information on the binary. You could also mount the image
> on your host OS and do the same. All we're looking for is to see whether
> the gcc binary has been compiled with --target 'arm.*'
>
> Regarding the compilation, I've had success with static links - although
> I've never tried  pthreads. You may want to see if there are significant
> changes between your host C library and the one that is present in your
> image.
>
>
> On Sat, Dec 27, 2014 at 3:08 AM, rahul shrivastava <
> [email protected]> wrote:
>
>> Forgot to paste the code
>>
>> Following is the code which is executed by each of the three thread
>>
>>
>> *        CPU_ZERO(&cpuset);        CPU_SET(data->thread_no+BASE,
>> &cpuset);* //This will make sure that thread no 1 is scheduled on CPU1,
>> thread no 2 on CPU2, and so on
>>
>>
>>
>>
>>
>> * s = pthread_setaffinity_np(thread, sizeof(cpu_set_t), &cpuset);
>> if (s != 0)                printf("pthread_setaffinity_np %d\n",s);
>> gettimeofday(&tp1,NULL);        for (i = 0; i < var/30; ++i)  *//c is
>> initialized to some value and value of var is passed as argument
>>
>>
>> *         {               c = c + i;         }*
>> *         gettimeofday(&tp2,NULL);*  //After this, I will take the
>> difference of the tp2 and tp1 to measure the time taken by the loop
>>
>>
>> Following is the code for the main thread which just creates three thread
>>
>>
>> * attrp = NULL;    for(i = 0;i < th;i++) {     *//th is 3 in my case
>>
>>
>>
>>
>>
>>
>> *        tdata = malloc(sizeof(thdata));        tdata->thread_no =
>> i;        tdata->iteration = iteration;        pthread_create (&thread1[i],
>> attrp, (void *) &print_message_function, (void *)tdata);    }    for(i =
>> 0;i < th;i++) {             *//wait for the three threads to terminate
>>
>> *        pthread_join(thread1[i],NULL);    }*
>>
>>
>> Is my way of compiling of the program inside the m5term is correct? Or do
>> I need to compile the program apriori and only keep the binary inside the
>> disk image? For the second option, since I am simulating a multi-threaded
>> program on ARM full system simulation, do I also need to compile the
>> pthreads library for ARM architecture, and only then I can statically link
>> the pthreads library to my program and keep my linked version of the
>> program inside the disk image ?
>>
>> Regards
>> Rahul
>>
>>
>> On Sat, Dec 27, 2014 at 12:20 PM, rahul shrivastava <
>> [email protected]> wrote:
>>
>>> Hi Guru,
>>>
>>> I am just using a default simpleatomic CPU and not O3CPU. I dont exactly
>>> understand how to run gdb. Do I need to run gdb inside the m5term terminal
>>> on my sample program, or do I need to start the gem.opt program with gdb ?
>>>
>>>
>>> Regards
>>> Rahul
>>>
>>> On Sat, Dec 27, 2014 at 8:28 AM, Guru Prasad <[email protected]>
>>> wrote:
>>>
>>>> Could you maybe paste the code? I haven't done any x86 simulations, but
>>>> multiple core runs on ARM simulations have run fine and completed
>>>> successfully for me. Also, if you're using O3CPU, then long running time is
>>>> quite possible given that you're stressing the CPU greatly (loop).
>>>> You could try to run the program within gdb and signal gdb to stop
>>>> after 6hours or so to check the status of the loop.
>>>>
>>>>
>>>> On Fri, Dec 26, 2014 at 12:15 AM, rahul shrivastava via gem5-users <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have configured per core dvfs for 4 core ARM system, following the
>>>>> steps mentioned in the website. After this I am performing the following
>>>>> steps to run my multi threaded code
>>>>>
>>>>> 1) Copy my sample code to the disk image
>>>>> 2) Start gem5
>>>>> 3) Start m5term and login as root
>>>>> 4) From m5term, see that all the 4 cores are online
>>>>> 5) From m5term, compile my multi- threaded code as
>>>>>             gcc <my_code.c> -lpthread -lm
>>>>> 6) From m5term, start my program as
>>>>>             ./a.out <my_prgm arguments>
>>>>>
>>>>> The program is a simple one which creates 3 threads and pins each
>>>>> thread to a core and each thread then loops for some fixed number of
>>>>> iterations.
>>>>>
>>>>> But, it is more than 12 hours that the program is running and not
>>>>> terminating.
>>>>> On my x86 machine, the program hardly takes a minute to run.
>>>>> Could you please let me know that whether the procedure I am following
>>>>> to run the program is correct
>>>>>
>>>>>
>>>>> Regards
>>>>> Rahul
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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

Reply via email to