Hi Jason,
Thanks a lot for your help! I've solved this problem.
Sincerely,
Liyan Chen
___
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
Hi Jason,
Thank you very much for your swift response. I hugely appreciate it.
Wishing you a great day.
Regards,
Tom
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cg
Hi Tom,
I'm not sure. Again, I'd add the Vma and the SyscallVerbose debug flags
which may help figure it out. It's possible that's the address of a
dynamically-loaded library as well.
Also, this trace looks like it came from Arm instead of x86. I don't
have as much experience looking at Arm addre
Hi Jason,
I have one doubt.
The following is some selected parts of Exec trace:
If we look at lines:
line 4: ldr x1, [sp]: MemRead : D=0x0001
A=0x7efe70
line 74 : ldr x1, [x0]: MemRead : D=0x0010
A=0x7efe90
line 88 :
Hi Liyan,
This looks like a stack address to me, so it won't appear in the objdump.
Since you're using SE mode, gem5 is controlling the physical address
mappings (not the OS). You can use the "Vma" debug flag to see all of the
virtual memory areas that gem5 creates/assigns. the "SyscallVerbose" f
