> Actually I originally planned to make the ppc64 syscall table different > from the ppc32 table, leaving out the unimplemented and 32-bit only > syscalls.
The kernel shares a single table in the source file. So the correlation of numbers to names is really not going to vary (just a few of them are only used on ppc32). IMHO it is better to print the names in case these ppc32-only syscalls are used in ppc64. > There are a lot of places that assume you can read sizeof(long) worth of > data from the u-area to read a register's contents. That won't work on > ppc32 targeting ppc64 whereas it works fine the other way round. It's really only a small handful of functions that use upeek. All that code would use PTRACE_GETREGS64 instead, and that is not much complexity. It's all the struct decoding that would really be a lot of tedious work. Anyway, my note was just for future reference and for clarity in our announcements of what newly works after your changes. If there were only the upeek calls to worry about, then I would probably try to talk you into implementing that. But I'm not suggesting that now. Thanks, Roland ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
