I''ve put the 2.6.25 rebase of utrace back in and kicked off a build. I''ll pick up the pieces if it comes out all broken. (It already did, cause I forgot to test the ppc32 build upstream.) For the moment it''s applied as one big patch instead of a series. I haven''t figured out the arrangement for the new series yet. There is some amount of mayhem going on and this rebase was kind of hack and slash. But there''s more churn than real change. About a third of the work is upstream now. All of the "quick and dirty" I''ve put together this week is actually either what''s already upstream or nearly identical to what''s been in F8 et al for a long time. So despite the late date and general disorganization of it all, this won''t be as destabilizing as it sounds. Thanks, Roland
On Wed, 2008-03-19 at 13:40 -0700, Roland McGrath wrote:> I''ve put the 2.6.25 rebase of utrace back in and kicked off a build. > I''ll pick up the pieces if it comes out all broken. > (It already did, cause I forgot to test the ppc32 build upstream.) > > For the moment it''s applied as one big patch instead of a series. > I haven''t figured out the arrangement for the new series yet. > > There is some amount of mayhem going on and this rebase was kind of hack > and slash. But there''s more churn than real change. About a third of the > work is upstream now. All of the "quick and dirty" I''ve put together this > week is actually either what''s already upstream or nearly identical to > what''s been in F8 et al for a long time. So despite the late date and > general disorganization of it all, this won''t be as destabilizing as it sounds. >Roland, There was an odd bug introduced by this on ia64. With your patch I get this build error: arch/ia64/kernel/entry.S: Assembler messages: arch/ia64/kernel/entry.S:723: Error: Operand 2 of `and'' should be an 8-bit integer (-128-127) arch/ia64/kernel/entry.S:723: Error: qualifying predicate not followed by instruction arch/ia64/kernel/entry.S:851: Error: Operand 2 of `and'' should be an 8-bit integer (-128-127) arch/ia64/kernel/entry.S:851: Error: qualifying predicate not followed by instruction This is caused by the change of #define TIF_RESTORE_SIGMASK 5 to #define TIF_RESTORE_SIGMASK 22 Is there a need to change this bit from 5 to 22? If that really is needed we are going to need to change entry.S to handle it (which I will need to find an ia64 asm expert for advice on this). thanks, - Doug
On Fri, 2008-03-28 at 14:35 -0400, Doug Chapman wrote:> On Wed, 2008-03-19 at 13:40 -0700, Roland McGrath wrote: > > I''ve put the 2.6.25 rebase of utrace back in and kicked off a build. > > I''ll pick up the pieces if it comes out all broken. > > (It already did, cause I forgot to test the ppc32 build upstream.) > > > > For the moment it''s applied as one big patch instead of a series. > > I haven''t figured out the arrangement for the new series yet. > > > > There is some amount of mayhem going on and this rebase was kind of hack > > and slash. But there''s more churn than real change. About a third of the > > work is upstream now. All of the "quick and dirty" I''ve put together this > > week is actually either what''s already upstream or nearly identical to > > what''s been in F8 et al for a long time. So despite the late date and > > general disorganization of it all, this won''t be as destabilizing as it sounds. > > > > Roland, > > There was an odd bug introduced by this on ia64. With your patch I get > this build error: > > arch/ia64/kernel/entry.S: Assembler messages: > arch/ia64/kernel/entry.S:723: Error: Operand 2 of `and'' should be an 8-bit integer (-128-127) > arch/ia64/kernel/entry.S:723: Error: qualifying predicate not followed by instruction > arch/ia64/kernel/entry.S:851: Error: Operand 2 of `and'' should be an 8-bit integer (-128-127) > arch/ia64/kernel/entry.S:851: Error: qualifying predicate not followed by instruction > > > This is caused by the change of > #define TIF_RESTORE_SIGMASK 5 > > to > > #define TIF_RESTORE_SIGMASK 22 > > > Is there a need to change this bit from 5 to 22? If that really is > needed we are going to need to change entry.S to handle it (which I will > need to find an ia64 asm expert for advice on this). > > thanks, > > - Doug >I did some hacking on the .S files that fail on the TIF masks to get that to build but it appears there is more ia64 code that needs to be updated to use utrace: arch/ia64/kernel/ptrace.c:1558: error: implicit declaration of function ‘ptrace_notify’ arch/ia64/kernel/ptrace.c:1559: error: ‘struct task_struct’ has no member named ‘ptrace’ (and so on...) So that we can continue to make ia64 progress can we %ifarch the utrace patch out in the spec file until utrace is complete on ia64? thanks, - Doug
Is there an alternate Koji or some other means by which I can try rawhide/ia64 rpm builds?> This is caused by the change of > #define TIF_RESTORE_SIGMASK 5 > > to > > #define TIF_RESTORE_SIGMASK 22 > > Is there a need to change this bit from 5 to 22? If that really is > needed we are going to need to change entry.S to handle it (which I will > need to find an ia64 asm expert for advice on this).This is part of a cleanup that is not yet needed. I''ll drop those patches from the series for now.> So that we can continue to make ia64 progress can we %ifarch the utrace > patch out in the spec file until utrace is complete on ia64?That should be fine. I don''t think other patches need it to apply. The hard 90% of the ia64 work (user_regset) has been done and posted upstream by Shaohua Li <shaohua.li@intel.com>. What would be best is if you can lean on linux-ia64 upstream to incorporate those changes ASAP. When the parts upstream has already seen get integrated, there will be little enough left for ia64 utrace to work that I can get it going. Thanks, Roland