[gem5-users] Re: Issue with strange virtual address access
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
[gem5-users] Re: Issue with strange virtual address access
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%(cgiext)s/%(_internal_name)s
[gem5-users] Re: Issue with strange virtual address access
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=0x0001 > A=0x7efe70 > line 74 : ldr x1, [x0]: MemRead : > D=0x0010 > A=0x7efe90 > line 88 : ldr x3, [x8, #3840]: MemRead : D=0x0001 > A=0x498f00 > line 92 : ldr x7, [x10, #3896] : MemRead : D=0x0001 > A=0x499f38 > line 152: ldr x28, [x0, #8]: MemRead : D=0x004471e3 > A=0x7efe98 > > 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
[gem5-users] Re: Issue with strange virtual address access
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 : ldr x3, [x8, #3840]: MemRead : D=0x0001 A=0x498f00 line 92 : ldr x7, [x10, #3896] : MemRead : D=0x0001 A=0x499f38 line 152: ldr x28, [x0, #8]: MemRead : D=0x004471e3 A=0x7efe98 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] Re: Issue with strange virtual address access
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" flag could also be useful. Cheers, Jason On Mon, Mar 21, 2022 at 12:46 AM liyan.chen--- via gem5-users < gem5-users@gem5.org> wrote: > Hi all, > > I used the following command to view the virtual address translation > process. > > build/X86/gem5.opt --debug-flags=Exec,TLB > --debug-file=/home/liyan/Desktop/gem5/m5out/debug.txt configs/example/se.py > --cpu-type=TimingSimpleCPU --caches --l2cache --mem-type=DRAMsim3 > --num-cpus=1 -c "tests/test-progs/hello/bin/x86/linux/hello" > > However, I found some strange virtual address such as 0x7fffee20 > > 56500: system.cpu.dtb: Translating vaddr 0x7fffee20. > 56500: system.cpu.dtb: In protected mode. > 56500: system.cpu.dtb: Paging enabled. > 56500: system.cpu.dtb: Handling a TLB miss for address 0x7fffee20 at > pc 0x400a55. > 56500: system.cpu.dtb: Mapping 0x7fffe000 to 0xbd000 > 56500: system.cpu.dtb: Miss was serviced. > 56500: system.cpu.dtb: Entry found with paddr 0xbd000, doing protection > checks. > 56500: system.cpu.dtb: Translated 0x7fffee20 -> 0xbde20. > > And it(0x7fffee20) also appears here(I don't know whether there is any > relationship) > > 56500: system.cpu T0 : @_start+5: pop rsi > 56500: system.cpu T0 : @_start+5.0 : POP_R : ldis t1, SS:[rsp] : > MemRead : D=0x0001 A=0x7fffee20 > 110500: system.cpu T0 : @_start+5.1 : POP_R : addi rsp, rsp, 0x8 : > IntAlu : D=0x7fffee28 > 110500: system.cpu T0 : @_start+5.2 : POP_R : mov rsi, rsi, t1 : > IntAlu : D=0x0001 > > Then I used following command to check the address in hello.dump file but > didn't find such address. > > objdump -D hello > hello.dump > > I'm not familiar with the compilation process and work flow of the core. > Does anyone know why these address exist? > > Any ideas are appreciated! Please reply if you have some advice. Thanks in > advance! > > 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 > ___ 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
