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. Dave -- J. David Anglin dave.anglin@xxxxxxxxxxxxxx National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- 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
