Hmm, seems like there's a little bit of an inconsistency in that the request is using the legacy.addr bit (which is set by the decoder when it sees the address size override prefix [1]) directly, while the legacy.addr bit is also used to calculate the addressSize value [2] but can be overridden (as we are doing). So if addressSize is overridden then AddrSizeFlagBit should no longer be set based on legacy.addr.
Or another way of looking at it is that the same process of checking legacy.addr to override the address size is done in two places, once in the decoder [2] and again in the TLB [3] and it's not clear how to suppress the latter one. I suppose one gnarly way of doing it would be to go into the micro-op definition somewhere and clear the AddrSizeFlagBit out of memFlags if addressSize != env.addressSize (i.e., the address size was overridden). There's probably a cleaner way, but that's the easiest path I can think of (if it even works). [1] http://grok.gem5.org/xref/gem5/src/arch/x86/decoder.cc#195 [2] http://grok.gem5.org/xref/gem5/src/arch/x86/decoder.cc#390 [3] http://grok.gem5.org/source/xref/gem5/src/arch/x86/tlb.cc#315 On Tue, Jan 24, 2017 at 8:37 AM, Jason Lowe-Power <ja...@lowepower.com> wrote: > Hi Steve, > > That was super helpful. I'm now a step closer to solving this! > > Your suggestion of =ssz, lead me to search for the uses of that in x86, and > it turns out that almost all of other stack instructions have dataSize=ssz. > So, I added both dataSize=ssz and addressSize=ssz to the call instruction, > though I think only the addressSize is actually needed, but I'm not > certain. > > Now, the address is passed to the Request object correctly, but the program > still fails. The problem now is that the request object is getting > the AddrSizeFlagBit set to true, because machInst.legacy.addr is true. > Thus, the TLB only uses the lower 32 bits of the 64-bit address. > > Any ideas on how to change the instruction's memFlags from the macro-op > definition? They are set on > http://repo.gem5.org/gem5/file/cd7f3a1dbf55/src/arch/ > x86/isa/microops/ldstop.isa#l334 > . > > It would be nice if we could fix this in the decoder. I think the logic > should be "if the address prefix is set and this is an implicit stack > operation, ignore the address prefix". However, I'm not sure how to tell if > the instruction is "an implicit stack operation" from the decoder. > > Thanks, > Jason > > On Tue, Jan 24, 2017 at 9:05 AM Steve Reinhardt <ste...@gmail.com> wrote: > > My recollection of how all this works is that the arguments to the 'st' > micro-op get turned into arguments to a call to the StoreOp constructor: > > 597 <http://repo.gem5.o, and that address doesn't > existrg/gem5/file/cd7f3a1dbf55/src/arch/x86/isa/microops/ldstop.isa#l597 > <http://repo.gem5.org/gem5/file/cd7f3a1dbf55/src/arch/ > x86/isa/microops/ldstop.isa#l597> > > > class StoreOp(LdStOp): > 598 < > http://repo.gem5.org/gem5/file/cd7f3a1dbf55/src/arch/ > x86/isa/microops/ldstop.isa#l598 > > > def __init__(self, data, segment, addr, disp = 0, > 599 < > http://repo.gem5.org/gem5/file/cd7f3a1dbf55/src/arch/ > x86/isa/microops/ldstop.isa#l599 > > > dataSize="env.dataSize", > 600 < > http://repo.gem5.org/gem5/file/cd7f3a1dbf55/src/arch/ > x86/isa/microops/ldstop.isa#l600 > > > addressSize="env.addressSize", > 601 < > http://repo.gem5.org/gem5/file/cd7f3a1dbf55/src/arch/ > x86/isa/microops/ldstop.isa#l601 > > > atCPL0=False, nonSpec=False): > > so the "-env.dataSize" you see is actually the displacement for the store, > not the dataSize or addressSize. I think the problem is that the > addressSize is using the env,addressSize that's calculated the "normal" > way, i.e., including the effects of the override prefix. > > Poking around some more, there's an 'ssz' symbol that maps to env.stackSize > [1] which gets used a lot in stack operations; for example, right after the > store in CALL_NEAR_I, 'ssz' is subtracted off of the stack pointer. The > calculation of env.stackSize seems to follow the rule you mentioned about > being fixed at 64 bits in 64-bit mode [2, 3]. > > So it might be sufficient to add ', addressSize=ssz' to the end of the 'st' > micro-op. Oddly though I don't see addressSize being set on any other stack > ops (just dataSize), so I wonder if this is a problem with other stack > instructions or not. If so, it might be useful to have an override > hardwired in at some lower level to check if the segment is ss and force > the address size to be stackSize (rather than adding this extra parameter > in a dozen different places). I wouldn't know where best to do that though, > so the manual override seems best for now. > > Steve > > [1] http://grok.gem5.org/xref/gem5/src/arch/x86/isa/microasm.isa#107 > [2] http://grok.gem5.org/xref/gem5/src/arch/x86/isa.cc#91 > [3] http://grok.gem5.org/xref/gem5/src/arch/x86/decoder.cc#400 > > > > > On Mon, Jan 23, 2017 at 4:04 PM, Jason Lowe-Power <ja...@lowepower.com> > wrote: > > > To those of you with more x86 ISA implementation knowledge than I have: > > > > I've been working through a bug one of our users found (thanks > Sanchayan!). > > It looks like current versions of ld use the 0x67 instruction prefix > > (address size override) as an optimization instead of using a nop. See > > https://www.sourceware.org/ml/binutils/2016-05/msg00323.html. > > > > This causes the call instruction to be decoded with with the "address > size > > override prefix", which is correct, in a sense. From what I can tell, > this > > is passed to the call instruction via "-env.dataSize" (see call > instruction > > implementation below). > > > > def macroop CALL_NEAR_I > > { > > # Make the default data size of calls 64 bits in 64 bit mode > > .adjust_env oszIn64Override > > .function_call > > > > limm t1, imm > > rdip t7 > > # Check target of call > > st t7, ss, [0, t0, rsp], "-env.dataSize" > > subi rsp, rsp, ssz > > wrip t7, t1 > > }; > > > > Now, the bug is, according to the x86 manual, "For instructions that > > implicitly access the stack segment (SS), the address size for stack > > accesses is determined by the D (default) bit in the stack-segment > > descriptor. In 64-bit mode, the D bit is ignored, and all stack > references > > have a 64-bit address size." See > > https://support.amd.com/TechDocs/24594.pdf page > > 9. > > > > Thoughts on how to fix this? > > > > Thanks, > > Jason > > _______________________________________________ > > gem5-dev mailing list > > gem5-dev@gem5.org > > http://m5sim.org/mailman/listinfo/gem5-dev > > > _______________________________________________ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev > > -- > > Jason > _______________________________________________ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
