Did you mean: [0x8048140-0x8048180]? This is part of linker relocation.
R_386_RELATIVE Created by the link-editor for dynamic objects. The relocation offset member gives the location within a shared object that contains a value representing a relative address. The runtime linker computes the corresponding virtual address by adding the virtual address at which the shared object is loaded to the relative address. Relocation entries for this type must specify a value of zero for the symbol table index. From: https://docs.oracle.com/cd/E19120-01/open.solaris/819-0690/chapter6-26/index.html R_386_IRELATIVE is similar to R_386_RELATIVE except that the value used in this relocation is the program address returned by the function, which takes no arguments, at the address of the result of the corresponding R_386_RELATIVE relocation. One use of the R_386_IRELATIVE relocation is to avoid name lookup for the locally defined STT_GNU_IFUNC symbols at load-time. Support for this relocation is optional, but is required for the STT_GNU_IFUNC symbols. From: https://www.uclibc.org/docs/psABI-i386.pdf *$readelf -r hello32* Relocation section '.rel.plt' at offset 0x134 contains 5 entries: Offset Info Type Sym.Value Sym. Name 080ce000 0000002a R_386_IRELATIVE 080ce004 0000002a R_386_IRELATIVE 080ce008 0000002a R_386_IRELATIVE 080ce00c 0000002a R_386_IRELATIVE 080ce010 0000002a R_386_IRELATIVE Ryan Gambord <gambo...@oregonstate.edu> On Sat, Oct 24, 2020 at 1:01 AM Derrick.Greenspan via gem5-users < gem5-users@gem5.org> wrote: > [This email originated from outside of OSU. Use caution with links and > attachments.] > 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
_______________________________________________ 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
