Re: [RFC] New thread testcase.

[Manoj Iyer <manjo@austin.ibm.com>]

Yes you are correct, I did note the same I can modify the testcase and
and incorporate other suggestions as well. Will that qualify for
acceptance?

Thanks
-----
manjo
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Cognito ergo sum                                                          +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

On Fri, 27 Aug 2004, Michael Snyder wrote:

> Manoj,
>
> It sounds from your eplanation like the "step" part of your test
> is not required, since your bug shows up without it.  I explained
> in my previous msg why I was concerned about that test.  What
> would you think of removing the step?
>
> Michael
>
> Manoj Iyer wrote:
> > oh! sorry abt that... got confused btwn 'bugs'...
> >
> > The kernel bug was causing gdb to fail when passing a 32bit address to the
> > kernel.  this was causing 32 bit gdb to fail in linux_test_for_tracefork()
> > by always returning second_pid = 0 in the PTRACE_GETEVENTMSG call.
> >
> > this resulted in linux_enable_event_reporting() not setting the PTRACE
> > fork options for the pid and then the thread never received a SIGSTOP.
> >
> > John Engel, kernel developer, debugged and fixed this problem in the
> > kernel after we reported this GDB problem to him...
> >
> > So, when you debug a multi-threaded app with 32bit GDB on a PPC64 system,
> > and you set a break point at the thread function and tried to step, you
> > get the message "reading register pc (#64): No such process." for example:
> >
> > Breakpoint 1, main (argc=1, argv=0xffffe464) at tbug.c:31
> > 31        for (n = 0; n < N; ++n)
> > (gdb) cont
> > Continuing.
> > [New Thread 1078217504 (LWP 26708)]
> > tf(0): begin
> > [New Thread 1082411808 (LWP 26709)]
> > after create
> > tf(1): begin
> > tf(0): end
> > [Thread 1078217504 (LWP 26708) exited]
> > tf(1): end
> > [Thread 1082411808 (LWP 26709) exited]
> > after join
> >
> > Program exited normally.
> > (gdb) clear main
> > Deleted breakpoint 1
> > (gdb) break tf
> > Breakpoint 2 at 0x10000594: file tbug.c, line 15.
> > (gdb) run
> > Starting program: /home/public/test-tools/gdb/tbug
> > [Thread debugging using libthread_db enabled]
> > [New Thread 1074020384 (LWP 26710)]
> > reading register pc (#64): No such process.
> > (gdb) cont
> > Continuing.
> > reading register pc (#64): No such process.
> >
> > Thanks
> > ----- ----
> > Manoj Iyer
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > + Cognito ergo sum +
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > On Tue, 10 Aug 2004, Andrew Cagney wrote:
> >
> >
> >>>>Manoj,
> >>>>
> >>>>>You've got me curious.  Do any of the existing tests exercise this bug
> >>>>>(manythreads.exp comes to mind)?   Oh, and what is the bug? :-)
> >>>>>
> >>>
> >>>
> >>>This is a generic kernel bug (in ptrace() )that causes ptrace to fail on
> >>>Power 64 systems.  Please look at PR#1712 for details.
> >>
> >>Unfortunatly 1712 doesn't answer my question.  What is the bug?  What
> >>causes ptrace to fail?
> >>
> >>Andrew
> >>
> >>
> >>
> >
> >
>
>
>