Hi Sam,
Are the (virtual, physical?) addresses different when you use the larger
arrays? I wonder if the underlying mmap or malloc calls are breaking in SE
mode somehow. Maybe, after you allocate in your guest code you can print
out the virtual address to make sure it looks reasonable. You can also use
a debug flag to print out the virtual->physical mapping that gem5 assigns
in the syscall_emul file, IIRC. That's where I would start.
Cheers,
Jason
On Thu, Jun 17, 2021 at 6:50 AM Thomas, Samuel via gem5-users <
gem5-users@gem5.org> wrote:
> Hi all,
>
> I'm writing because I'm trying to run a relatively simple, but
> memory-intensive C microbenchmark in SE mode. In particular, it allocates
> and randomly fills a 2MB array, then performs *n* random accesses to the
> array and increments the value.
>
> The program outputs that it is increasing the stack size by a page ("info:
> Increasing stack size by one page."), and eventually no more output is
> produced. I tried putting some sanity check code in the LLC logic (i.e.,
> print "Hello, does this work" every 10,000 accesses), and it seems as
> though the system has actually stopped executing.
>
> What's weird about this is that the program works for smaller arrays, such
> as 10kB, but those are somewhat uninteresting for my work. I suspect I'll
> have to turn to full system mode, but ideally I'd like to work with a
> simpler architecture.
>
> Is there any reason why this might be the case?
>
> Thank you for your help!
>
> Best,
> Sam
> _______________________________________________
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
