Your patch looks reasonable. You likely already did this, but since you're working with m5-stable which is fairly old, please be sure to check the development repository just in case your problem was already fixed. I just checked and this isn't there either, but that's one of the hazards of using m5-stable.
There are two levels the behaviors of traps are defined at as far as I know. The first, which you'll find in arch/sparc/process.cc, are for traps defined in the SYSV ABI. These are generally not used and not implemented, with the particular exception of the register window flushing trap. These are all documented in the SYSV ABI SPARC processor supplement you should be able to find through Google. The next level is where Linux defines behaviors for the traps the SYSV ABI leaves undefined. I don't know of any actual documentation, but if you look in the kernel source in arch/sparc64/kernel/ttable.S (my kernel tree is version 2.6.27.10 in case it moved) you'll find a table of all the vectors for all the traps. One thing I had to do some digging to explain/rediscover is that all the software trap vectors automatically have 256 added to them to disambiguate them from hardware vectors. That means that software trap number 0x6e actually corresponds to table entry 0x16e, which is convenient to locate because of the BTRAP entries that let you know how far you are into the list. 0x6d is the LINUX_64BIT_SYSCALL_TRAP entry which is handled by the 64 SPARC process object, and 0x6e and 0x6f immediately after it are for sparc64_get_context and sparc64_set_context, whatever those do. I'm guessing it either has something to do with user level thread support and/or thread local storage. Reading the glibc source or finding information about those functions in the kernel source would probably help explain what's going on. Assuming glibc is just setting up some facility that your benchmark(s) never happen to use, it would be locally safe to ignore that trap number. In a more global context we'd want to at least warn(). Gabe Ioannis Ilkos wrote: > Hello, > > I have been using the m5-stable from the repository the last few days. In > order to compile sparc64-linux binaries for SE mode I built a cross compiler > toolchain which linked against newer glibc versions. It turned out the newer > glibc (my test programs were linked with glibc-2.8 with support down to > kernel 2.6.12) needed an implementation of the writev. I have attached the > relevant patch, it should work (haven't done any extensive testing, but there > is no reason it shouldn't since it just uses the templated writev from other > architectures). > > In addition, within glibc code I got an unhandled trap with the message: > panic: Unimplemented trap to operating system: trap number 0x6e. > Adding a dummy implementation for this trap will allow the code to execute > fine. However, what is this trap supposed to be? Is there a reference for it > somewhere? > > Thanks, > Ioannis > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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
