What I did for either SPARC or x86 (or both?) was that I made that function templated on a type instead of taking intSize. Then you can call it with however large a type you need and it should work out. You'll also probably want separate MIPS32 and MIPS64 process objects since syscalls may be different, for instance. Did you cast both of the addresses you passed to copyStringArray?
Gabe Korey Sewell wrote: > Hey Gabe, > the point of interest in the code is here: > > + // ======== > > + // NOTE: Using uint32_t hardcodes MIPS32 and not MIPS64 > > + // even if MIPS64 was intended. This is because the > > + // copyStringArray function templates on the parameters. > > + // Elegant way to check intSize and vary between 32/64? > > + // ======== > > + uint32_t argv_array_base = stack_min + intSize; // room for argc > > + uint32_t envp_array_base = argv_array_base + argv_array_size; > > + uint32_t arg_data_base = envp_array_base + envp_array_size; > > + uint32_t env_data_base = arg_data_base + arg_data_size; > > Where you see "uint32_t" there is an "Addr" in sim/src/process.cc. > Depending on the intSize we need to be > able to send to the copyStringArray() a uint32_t or a uint64_t. I > tried a straight typecast but that just > changes the value, and you cant dynamic/reinterpret cast because it's > not a pointer. > > Didn't try maybe giving it a bit union. OR, if there is a way to force > that templated function via a > copyStringArray<uint32_t> then I suppose that could work as well. > > Once that gets figured out, then as you suggest in the subsequent > email placing some of this common code that has found its way into 3/4 > separate files might be nice. > > -K > ------------------------------------------------------------------------ > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
