On Sun, Mar 28, 2010 at 10:38 PM, John David Anglin <dave@xxxxxxxxxxxxxxxxxx> wrote: > On Sun, 28 Mar 2010, Carlos O'Donell wrote: > >> On Sun, Mar 28, 2010 at 7:59 PM, John David Anglin >> <dave@xxxxxxxxxxxxxxxxxx> wrote: >> >> I know it's easier to debug a static application for these cases, so I >> >> think a fixed glibc will help. >> > >> > Yes. >> > >> > It's proving more difficult than I thought to fix the kernel and >> > I'm not sure I understand how this works: >> > >> > LDREG TI_TASK-THREAD_SZ_ALGN-FRAME_SIZE-FRAME_SIZE(%r30), %r1 >> > LDREG TASK_PT_GR19(%r1),%r2 >> > b wrapper_exit >> > copy %r0,%r28 >> > >> > It appears the child has to access the parent's pt_regs struct >> > to load the return for the child. >> >> I see that copy_process in do_fork will give the child a copy of the >> entire pt_reg structure so it has access to these values anyway? > > I got a kernel to boot which shouldn't clobber r19. Turned out to > be a typo. This uses PT_SR4 for the kernel return for the child. > Will test with gcc build. > > Will try again using the pad0 field later. Sorry, what turned out to be a typo? I guess any static binary that calls fork/vfork/clone is susceptible to corruption of r19 in this way. I don't know how much that effects userspace, since most is shared, *however* the dynamic linker is technically a static binary :-) Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
