Hi Tom. The data could have been written there as the result of a system call which would not have executed as instructions in gem5, or it could have been part of the initial binary. The address looks like a stack address, so there's a good chance it came from a system call.
I'm just guessing, but I would assume that the memory data that's printed is just printing the lowest byte because it's easy to know how to print a single byte, and you can assume there is always at least one. The load is probably loading the entire register even if it's only printing the first byte. On Tue, Mar 22, 2022 at 6:18 AM tom jose via gem5-users <gem5-users@gem5.org> wrote: > Hi , > I have attached a shorter Exec trace to this message. > 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. > Could you please provide an insight on how these addresses are loaded with > these data? Is it related to the Symbol Table? > > Any information on the same would hugely help. I have attached the binary > file for reference as well. > Thanks in advance for your help. > Regards, > Tom > > On Mon, Mar 21, 2022 at 11:32 AM tom jose <tomjosekalloo...@gmail.com> > wrote: > >> Hi , >> I was going through the load and store instructions from the GEM5 traces >> and i could see that at some instances, the load instruction reads from an >> address which was not written with valid data before. How is it reading >> non-zero data from an address which was not written to? (From the GEM5 >> traces, there was no store done to the address to which we are trying to >> read later on) >> Example: >> ldr x28, [x0, #8] >> lets say address = 0x7ffffefe28 >> and this results in reading 0x00000000004471e3 and storing in x28 >> But there was no memory write to 0x7ffffefe28 done prior. So how are we >> getting 0x00000000004471e3? >> >> Also, I tried running the simulation with Debug-Flags as "All" and i >> could see : >> system.cpu_cluster.cpus.execute: Memory data[0]: 0xe3 >> the e3 is the lower bits in the data which is read. So how is the upper >> bits obtained? >> >> details on the run: >> ./build/ARM/gem5.opt --debug-flags=All --debug-file=bm1_a77_trace >> ./configs/example/arm/starter_se.py --cpu minor --cpu-freq 3.0GHz >> --mem-type DDR4_2400_8x8 ./tests/bm1 >> >> So is there a way to identify which process is writing data to these >> addresses? Can i get them printed out to the GEM5 traces? >> >> Please let me know if you require more information from my end. >> 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
