Is there any actual benefit to arch=powerpc64 and the separate directory of files that all just #include the powerpc files? I think we'd do as well just to leave arch=powerpc for the powerpc64 configuration. It doesn't seem likely that these lists will diverge for ppc32/ppc64 in the future.
It's fine enough to use a < 0 test for the MSR, where we're testing the high bit because that happens to be the relevant flag. But it merits a comment that this constitutes a test of the MSR_SF_LG bit. I haven't really checked over all the individual biarch cases or potential needs for them. They look fine and I assume you've checked the details. For NEWS and the like we should make clear that this only permits a ppc64 build of strace to handle ppc32 tracees, not vice versa. This is exactly equivalent to the situation on x86_64/i386, but the context may differ. That is, there are powerpc systems where it's normal to have most of userland (including strace) be ppc32 and only the kernel and some userland things be ppc64. To support those systems more smoothly, we could also make ppc32 strace use PTRACE_GETREGS64 to support ppc64 tracees, but that would require much more work in the inverse biarch decoding support. 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
