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 addresses and guessing the meaning :). Cheers, Jason On Tue, Mar 22, 2022 at 8:32 AM tomjosekallooran--- via gem5-users < gem5-users@gem5.org> wrote: > 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=0x0000000000000001 > A=0x7ffffefe70 > line 74 : ldr x1, [x0] : MemRead : > D=0x0000000000000010 > A=0x7ffffefe90 > line 88 : ldr x3, [x8, #3840] : MemRead : D=0x0000000000000001 > A=0x498f00 > line 92 : ldr x7, [x10, #3896] : MemRead : D=0x0000000000010000 > A=0x499f38 > line 152: ldr x28, [x0, #8] : MemRead : D=0x00000000004471e3 > A=0x7ffffefe98 > > Prior to these lines, there was no MemWrite to the corresponding address. > Is this also related to Stack addresses?Could you please provide an insight > on how these addresses are loaded with these data? > > Any information on the same would hugely help. > > 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%(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
