getcontext() and setcontext() seem far more evil than updating a simple TLS register. getcontext() seems to copy all of the processor/process state into a struct and return that to the user. setcontext() takes something from getcontext() and restores it (including things like the PC).
http://www.kernel.org/doc/man-pages/online/pages/man2/setcontext.2.html Ali On Mon, 12 Jul 2010 00:26:53 -0700, Gabe Black <[email protected]> wrote: > 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 _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
