Thanks a lot for the information, the +0x100 part on the trap table is what had me confused.
Turns out that the glibc implementation of sigsetjmp / siglongjmp is based on the get_context / set_context traps respectively (see <glibc>/sysdeps/unix/sysv/linux/sparc/sparc64/setjmp.S for example). I believe it is used in ELF loading code but I have not looked into it. The respective kernel implementations of the trap handlers are pretty straightforward (arch/sparc64/kernel/signal.c). Essentially get_context copies the arch state (pc, npc, %g, %i regs and some other things) into the userland. I might implement them if I can get some free time. Until then, I guess that just adding a warning should suffice - as long as you siglongjmp is not called there shouldn't be a problem. Ioannis On 12 Jul 2010, at 08:26, Gabe Black 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 >> m5-dev@m5sim.org >> http://m5sim.org/mailman/listinfo/m5-dev >> > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
