So you are saying, it is not the address that the store instruction is supposed to store the value, but rather the address of the instruction itself ? The left-most boldface below:
0x41c0ec @_dl_debug_initialize+124 : stlr x0, [x3] : MemWrite : D=0x0000000000492000 *A=0x498028 That is, the program counter, when trying to fetch 0x41c0ec, could not find this address in one cacheline ? But, it was able to execute some previous instructions, and if cacheline size of instruction cache was the issue, the program should have terminated way before it reached this instruction. Here are some debug info from debug flag=LSQunit 122942000: system.cpu.iew.lsq.thread0: Inserting store PC (0x41c0ec=>0x41c0f0).(0=>1), idx:933 [sn:6577] 122942500: system.cpu.iew.lsq.thread0: Executing store PC (0x41c0ec=>0x41c0f0).(0=>1) [sn:6577] 122942500: system.cpu.iew.lsq.thread0: Fault on Store PC (0x41c0ec=>0x41c0f0).(0=>1), [sn:6577], Size = 0 Then I see the squashing messages and right after that the page fault messages appear. I looked into page table, and it receives the addres 0x400, cannot find page for this (and consequently the physical address). Then the fixfault() method in mem_state.cc is called, which cannot assign a new page, I am guessing because it is not in the VMA list. Thus I was thinking, maybe it is an address generation issue. I looked into (just skimmed through) arch/arm/insts/macromem.cc and mem.cc, it does have separate conditions for 32 bit and 64 bit (although the EA is not here, the are in ISA files). My best guess is, 0x400 is a partial address, the later parts of this are lost because of 64/32 bit issue. ________________________________ From: Eliot Moss <m...@cs.umass.edu> Sent: 06 February 2024 10:38 To: The gem5 Users mailing list <gem5-users@gem5.org> Cc: Nazmus Sakib <nsak...@nmsu.edu> Subject: Re: [gem5-users] Re: Effective address and ISA [You don't often get email from m...@cs.umass.edu. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] WARNING This email originated external to the NMSU email system. Do not click on links or open attachments unless you are sure the content is safe. On 2/6/2024 11:13 AM, Nazmus Sakib via gem5-users wrote: > I think gem5 has this SplitDataRequest() method that breaks the request if it > would need more than one cacheline. > In fact, the page fault is occurring before it goes to the cache. The panic > message says the address is 0x400. By > looking into the disassembly and the output log of -debug-flag=ExecAll, I > think the address is an instruction address, > as I have found addresses starting with 0x400, for example : > 0x400bf8 @__libc_start_main+808 : movz x1, #0, > > Although, the last instruction I see in the output from ExecAll flag is a > store instruction: > 0x41c0ec @_dl_debug_initialize+124 : stlr x0, [x3] : MemWrite > : D=0x0000000000492000 *A=0x498028* > Right after this, the panic message occurs. > In fact, using debug-flag=LSQUnit, I can see the message that "Fault on store > pc" which points to this store instruction. Yes, it *can* split requests; I'm just not sure it's prepared to do in this case. Since you have mentioned instructions, I'm now wondering if there could be an issue with really small instruction cache lines. The store might be faulting because of address translation, but it might also be faulting because of ordering constraints (it's a store release instruction). It is 64-bit, which means it would cross cache lines. Maybe that's disallowed for such ordering ops? EM
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
