Ah, I was trying to do this from arch/arm/process.cc, but I've found
sim/Process.py which seems to actually control what the value is (at least when
using the se.py config).
Turns out Process.py already sets a 64MB stack by default. This suggests GCC
crashing isn't due to running out of stack
you may have below python coding in your *.py configuration file:
process = Process(...)
process.executable = ...
If you want to update the stack base, just add configuration like below:
process.stackBase = 0x // new stack base value
process.maxStackSize = 0x // stack size
You can
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,
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
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
Hi,
I have ever met several similar issues but i'm not running Spec2017. I think
that's because you use this address 0x66195c 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
