Hello everyone,
Bear with me here, as this is a complicated question:
I am porting a memory system simulator originally developed as an extension to
Multi2Sim to Gem5. Until now, all was more-or-less straightforward in the
porting process.
However, for the past three months, I've been fighting a very strange issue.
Using the default hello32 binary, the CPU attempts to read a particular cache
line (0x140) as data, writing it into its L1D cache, and then attempts to read
it as an instruction, attempting to write it into its L1I cache. From what I
know, this should not be possible -- a cache line can only contain either
instructions, or data, but not both. Neither ruby nor the default gem5 cache
implementation have any issue with this behavior. However, the memory system I
am porting certainly does!
I have tried everything to figure out why this is happening. I can say that the
cache line maps to part of the .rel.plt segment of the hello32 binary --
specifically, virtual addresses [0x8048140-0x804180], and these virtual
addresses appear to me to be instructions rather than data. So, I am not at all
sure why gem5 loads this as data first.
The instruction which causes the initial data load, according to the request
packet, is cmp byte [ebx*8 + 0x8048138], 0x2a -- program counter 0x80489b0,
which is in .text (so it is appropriately an instruction). The instruction
which causes the later instruction fetch, according to that request packet, is
push ebp -- program counter 0x804815c, which is the start of the function
prologue for __rel_iplt_end().
But I remain completely at a loss as to why this is happening. Is this in fact
proper behavior? My impression is that except in very specific circumstances,
there is a strict separation between instructions and data, and each cache line
(and even operating system level page) can be only one or the other. Is there
something I simply do not know about either x86 assembly, or caches in general,
that indicates that this behavior is appropriate?
Thank you for any help you can provide. Hopefully, I can figure this out soon!
All the best,
Derrick Greenspan MSCS
PhD Graduate Research Assistant
University of Central Florida
_______________________________________________
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
