While trying to run alpha ld.so with M5 in the syscall emulation mode, I noticed something that I don't quite understand. As far as I can follow the code, when the emulated system calls do copyin/copyout they do not do the VA/PA translation step.
Normally this apparently is not a problem as the syscall emulation mode uses dummyTranslation(). But ld.so seems to get its stack into the very top of the address space. So when ld.so calls uname() the result gets written to 0xfffffffffff96e28, but when the following code tries to access the result, the access goes through the translation step and dummyTranslation clears the upper 16 bits of the addresses. And the code gets the data from a different address. Just for testing purposes I changed the dummy translation to do nothing and naturally then the accesses happen to the right address but I suppose this is not the right solution. Should'n the syscall emulation copyin/copyout be changed to do the translation step? Another question - does ld.so get its stack into the very top of the VA on real alpha? Or is this an anomaly of trying to run a shared object in M5? I suppose making shared libs work would require better mmap() than the current. With current mmap() ld.so thinks everything is statically linked :-) -- http://www.iki.fi/~ananaza/ ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ m5sim-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/m5sim-users
