I see, thanks for the explanation.
Could you elaborate for me how I should change the stack base address to
increase available size? I had thought setting a higher address would but GCC
immediately crashes if I do this. If I set a lower address it works but does
this provide more space?
Also, is the mmap_end variable relevant at all?
Sent from Proton Mail mobile
-------- Original Message --------
On 16 Jan 2024, 06:07, sun2k23 wrote:
> Hi,
>
> Usually in SE mode, the page would be pre-allocated when the ELF file(what's
> also called image download by me previously) is initiated/downloaded to the
> memory. The allocated page can be checked when enabling MMU debug-flag.
>
> I would suggest you to check the error address to confirm whether the related
> page is allocated, and probably not, then you would check whether the error
> address is located inside stack location or somewhere else. if it's outside
> stack and is an invalid location, maybe you should further enlarge the stack
> space. except for the process.StackSize, i think maybe you should also modify
> the process.stackBase.
>
> Please let me know if you fix this issue.
>
> Regards,
> S2K.
>
> At 2024-01-15 09:25:02, "muke101 via gem5-users" <gem5-users@gem5.org> wrote:
>
>> Hi, thanks for the reply.
>>
>> Assuming that the page isn't being allocated when it should be, what could I
>> do with this information? I'm not familiar with this part of the Gem5
>> codebase.
>>
>> Also, just to be clear, what do you mean by 'when the image download is
>> done'?
>>
>> Thanks.
>>
>> Sent from Proton Mail mobile
>>
>> -------- Original Message --------
>> On 15 Jan 2024, 01:18, sun2k23 via gem5-users wrote:
>>
>>> Hi,
>>>
>>> I have ever met several similar issues but i'm not running Spec2017. I
>>> think that's because you use this address 0x660000195c before allocating
>>> page firstly. You can enable the debug-flag of MMU to check whether the
>>> page related to this address is allocated when the image download is done.
>>>
>>> S2k
>>>
>>> At 2024-01-14 04:40:13, "muke101 via gem5-users" <gem5-users@gem5.org>
>>> wrote:
>>>
>>>> Hi, I'm trying to checkpoint spec2017 with NonCachingSimpleCPU according
>>>> to simpoints I generated from native AArch64 binaries. On an unmodified
>>>> Gem5, a page fault occurs in the simulation (pasted the error message at
>>>> the bottom).
>>>>
>>>> I've read that GCC can run out of stack space when simulated, so I edited
>>>> arch/arm/process.cc to have a max stack size of 16MB instead of the
>>>> default 8MB, but this hasn't helped. Can someone confirm this is the right
>>>> way to increase the max stack size? The total memory allowed to the
>>>> simulation if 50GB (set if --mem-size on the command line).
>>>>
>>>> Another possibility is that it's due to me compiling the benchmark without
>>>> '--no-strict-aliasing', which the spec documentation suggests to, but I
>>>> imagine if this were the problem then the program wouldn't had been able
>>>> to run natively, which it does.
>>>>
>>>> Has anyone run into this problem before and been able to solve it?
>>>>
>>>> Thanks.
>>>>
>>>> build/ARM/sim/simulate.cc:194: info: Entering event queue @
>>>> 188431954680500. Starting simulation...
>>>> build/ARM/sim/faults.cc:104: panic: panic condition !handled &&
>>>> !tc->getSystemPtr()->trapToGdb(SIGSEGV, tc->contextId()) occurred: Page
>>>> table fault when accessing virtual address 0x660000195c
>>>> Memory Usage: 52735052 KBytes
>>>> Program aborted at tick 191641021589000
>>>> --- BEGIN LIBC BACKTRACE ---
>>>> /sim_home/luke/PND-Loads/gem5/build/ARM/gem5.fast(+0x97d088)[0xaaaaca97c088]
>>>> /sim_home/luke/PND-Loads/gem5/build/ARM/gem5.fast(+0x9ef1bc)[0xaaaaca9ee1bc]
>>>> linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0x4000161c2688]
>>>> /lib/aarch64-linux-gnu/libc.so.6(raise+0xb0)[0x4000164c2598]
>>>> --- END LIBC BACKTRACE ---
>>>> Aborted (core dumped)
>>>>
>>>> Sent with [Proton Mail](https://proton.me/) secure email.
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
