| Message ID | 1349344936.2706.10.camel@dabdike.int.hansenpartnership.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On Thu, Oct 04, 2012 at 11:02:16AM +0100, James Bottomley wrote: > It's plausible. I just verified the theory that the branch is redundant > by successfully booting with this patch applied. Somewhat related question: does CONFIG_HPUX work at all? What we have there is this: mfctl %cr30,%r1 xor %r1,%r30,%r30 /* ye olde xor trick */ xor %r1,%r30,%r1 xor %r1,%r30,%r30 ldo TASK_SZ_ALGN+FRAME_SIZE(%r30),%r30 /* set up kernel stack */ followed by saving registers into &((struct task_struct *)cr30)->thread.regs. cr30 contains something very different, though - struct thread_info *. Had been that way since 2002 or so. And after we'd been finished with syscall, we'll get to hpux_syscall_exit, tweak r22/r28 a bit and sod off to syscall_exit. Which does mfctl %cr30, %r1 LDREG TI_TASK(%r1),%r1 and eventually restores the values of registers saved in &(struct task_struct)r1->thread.regs. Except that here the value of r1 is ((struct thread_info *)cr30)->task, not cr30 itself. Which matches what we have in current.h (and do_fork(), etc.), but not what we'd done when we entered the syscall. IOW, the values we restore will have nothing to do with what we saved. Unless I'm missing something really subtle, it looks like HPUX compat had been very noticably broken since at least 2002. Comments? -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2012-10-04 at 13:22 +0100, Al Viro wrote: > On Thu, Oct 04, 2012 at 11:02:16AM +0100, James Bottomley wrote: > > > It's plausible. I just verified the theory that the branch is redundant > > by successfully booting with this patch applied. > > Somewhat related question: does CONFIG_HPUX work at all? I don't believe so. It's been bitrotting for some time. > What we have there > is this: > mfctl %cr30,%r1 > xor %r1,%r30,%r30 /* ye olde xor trick */ > xor %r1,%r30,%r1 > xor %r1,%r30,%r30 > ldo TASK_SZ_ALGN+FRAME_SIZE(%r30),%r30 /* set up kernel stack */ > followed by saving registers into &((struct task_struct *)cr30)->thread.regs. > cr30 contains something very different, though - struct thread_info *. > Had been that way since 2002 or so. And after we'd been finished with > syscall, we'll get to hpux_syscall_exit, tweak r22/r28 a bit and > sod off to syscall_exit. Which does > mfctl %cr30, %r1 > LDREG TI_TASK(%r1),%r1 > and eventually restores the values of registers saved in > &(struct task_struct)r1->thread.regs. Except that here the value of r1 is > ((struct thread_info *)cr30)->task, not cr30 itself. Which matches what we > have in current.h (and do_fork(), etc.), but not what we'd done when we > entered the syscall. IOW, the values we restore will have nothing to do > with what we saved. > > Unless I'm missing something really subtle, it looks like HPUX compat had > been very noticably broken since at least 2002. Comments? I think it probably has. I don't believe there's anyone left with hpux binaries actually checking it. James -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 4, 2012 at 8:57 AM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: >> Unless I'm missing something really subtle, it looks like HPUX compat had >> been very noticably broken since at least 2002. Comments? > > I think it probably has. I don't believe there's anyone left with hpux > binaries actually checking it. Was the HPUX support ever completed? I had HPUX/Linux dual-boot on one of my systems and I was never able to run an HPUX binary correctly. Someone with the time and inclination is all that is missing to cleanup the rotten HPUX bits. There is no need to keep any of it around, that's what version control is for. Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 04, 2012 at 09:30:16AM -0400, Carlos O'Donell wrote: > On Thu, Oct 4, 2012 at 8:57 AM, James Bottomley > <James.Bottomley@hansenpartnership.com> wrote: > >> Unless I'm missing something really subtle, it looks like HPUX compat had > >> been very noticably broken since at least 2002. Comments? > > > > I think it probably has. I don't believe there's anyone left with hpux > > binaries actually checking it. > > Was the HPUX support ever completed? > > I had HPUX/Linux dual-boot on one of my systems and I was never able > to run an HPUX binary correctly. > > Someone with the time and inclination is all that is missing to > cleanup the rotten HPUX bits. > > There is no need to keep any of it around, that's what version control is for. FWIW, parisc seems to be the last architecture to keep such thing - sparc and mips had dropped SunOS/Solaris/IRIX compat, iBCS* is long-dead (and hadn't been in mainline kernel anyway). Alpha might still be able to run some OSF binaries, but there the situation is different - no alternative syscall entry codepath, Linux just uses the same ABI and shares syscall numbers where possible... -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 4-Oct-12, at 10:07 AM, Al Viro wrote: > On Thu, Oct 04, 2012 at 09:30:16AM -0400, Carlos O'Donell wrote: >> On Thu, Oct 4, 2012 at 8:57 AM, James Bottomley >> <James.Bottomley@hansenpartnership.com> wrote: >>>> Unless I'm missing something really subtle, it looks like HPUX >>>> compat had >>>> been very noticably broken since at least 2002. Comments? >>> >>> I think it probably has. I don't believe there's anyone left with >>> hpux >>> binaries actually checking it. >> >> Was the HPUX support ever completed? >> >> I had HPUX/Linux dual-boot on one of my systems and I was never able >> to run an HPUX binary correctly. >> >> Someone with the time and inclination is all that is missing to >> cleanup the rotten HPUX bits. >> >> There is no need to keep any of it around, that's what version >> control is for. > > FWIW, parisc seems to be the last architecture to keep such thing - > sparc > and mips had dropped SunOS/Solaris/IRIX compat, iBCS* is long-dead > (and hadn't > been in mainline kernel anyway). Alpha might still be able to run > some OSF > binaries, but there the situation is different - no alternative > syscall > entry codepath, Linux just uses the same ABI and shares syscall > numbers > where possible... I believe the HP-UX support should be removed. I think it unlikely that anyone will complete the HP-UX implementation. For example, HP-UX has a 64-bit context for 32-bit applications when running a wide PA2.0 kernel. Linux only has a 32-bit context. As a result, it's not possible to exploit the 64-bit registers and instructions in Linux. We also don't have a 64-bit linux port, so 64-bit HP-UX support is impossible. There are quite a few other issues. Dave -- John David Anglin dave.anglin@bell.net -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S index 18670a0..d1da93f 100644 --- a/arch/parisc/kernel/entry.S +++ b/arch/parisc/kernel/entry.S @@ -1893,15 +1893,7 @@ ENDPROC(sys_vfork_wrapper) ldo -FRAME_SIZE(%r30),%r30 LDREG -RP_OFFSET(%r30),%r2 - - /* If exec succeeded we need to load the args */ - - ldo -1024(%r0),%r1 - cmpb,>>= %r28,%r1,error_\execve - copy %r2,%r19 - -error_\execve: - bv %r0(%r19) + bv %r0(%r2) nop .endm