> This patch ("change callers to use step = 0") can't break arch's ?
> Currently tracehook_report_syscall_exit() ignores "int step" argument,
> the patch doesn't change the compiled code at all.Oh, yes. That's true. I still don't like it. The existing arch code is right today. So you'll change it to wrong only to change it back later. That makes no sense to me. Only on x86 does the tracehook call really need to change. I wouldn't touch it on the others--unless you decide to roll in the arch hook to that API somehow, which I don't think would come out pretty enough to warrant it. > Not sure I understand. You mean, if arch hook is not defined, we add > the default arch_fill_sigtrap_info (or whatever) which only sets si_signo? Right. To be more precise, I think the arch hook should only set what's arch-specific and nonzero, so have generic code zero-fill and set si_signo. The arch hook just sets si_code et al, so that if there is no arch hook then the default one is empty. The arch code will only ever define what it needs to add vs that default. > > If you do the patches in the right order, then there will never > > even be a tree state where powerpc et al get any change at all before the > > final one. > > I am confused again. If we do the above, then powerpc's behaviour will > be changed iimediately? Not only powerpcs. parisc, ia64, etc. What I meant is that we can do: 1. specify arch hook, define default case 2. define powerpc's arch hook 3. change tracehook_report_syscall_exit to look at step flag 4. define x86's arch hook 5. change x86 tracehook_report_syscall_exit to match common pattern Then powerpc goes from status quo (ptrace_notify as if PTRACE_SYSCALL) to final status (SIGTRAP with correct si_code) in #3. In another order we might have an intermediate status where powerpc is sending SIGTRAP with si_code=0, which is suboptimal. That's not really a big deal though. What's important is that we can have a mergeable tracehook.h patch (#3) without waiting for all the arch's to merge their updates to define the arch hook. I can write the powerpc one as demonstration, and if the arch/powerpc maintainers are slow to approve/merge it then they might get the si_code=0 state on powerpc for a while, but that is OK. We can write and submit the x86 changes; only those will depend on the generic change having gone in first to avoid any intermediate tree state with a regression. Thanks, Roland
