Re: [PATCH] 0001-Fix-multi-thread-debug-bug-in-AIX.patch

[Ulrich Weigand <Ulrich.Weigand@de.ibm.com>]

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>>So this last bit seems to be the problem.  Could you elaborate on
>>what the exact call stack is?  I thought once the thread layer is
>>initialized, calls to ::wait should always go through it ...
>
>Kindly see the backtrace sections 
>BT:- Thread_wait [which is on a thread event like new thread born or main process is pthreaded],  
>BT:- Post thread wait in rs6000-aix-nat::wait  [which is the beneath ()->wait () in aix_thread_target::wait], 
>BT:- If direct rs6000-aix-nat::wait [ where in output 3 and 4 {below in this email} you can see it will directly come to rs6000-aix-nat.c if the main process after having threads forks or uses a fork () call ] pasted below in this email. 

I'm only replying to this is right now, because that seems to
be the fundamental problem that ultimately causes a lot of the
other issues you're seeing.

It seems the core problem is that you're not initializing the
thread layer correctly for any but the first inferior!  So all
other inferiors started with fork are assumed to be single-
threaded ...

If you look at a backtrace like this:

>BT:- If direct rs6000-aix-nat::wait
>
>Thread 1 hit Breakpoint 2, rs6000_nat_target::wait (this=0x1100a2e10 <_rs6000aixnat.rw_>, ptid=..., 
>    ourstatus=0xffffffffffff360, options=...) at rs6000-aix-nat.c:695
>695           set_sigint_trap ();
>(gdb) bt
>#0  rs6000_nat_target::wait (this=0x1100a2e10 <_rs6000aixnat.rw_>, ptid=..., 
>    ourstatus=0xffffffffffff360, options=...) at rs6000-aix-nat.c:695
>#1  0x0000000100340778 in target_wait (ptid=..., status=0xffffffffffff360, options=...) at target.c:2598

you see that the target.c code uses the current inferior's
"top_target" to find the appropriate target routines:

  target_ops *target = current_inferior ()->top_target ();
[...]
      ptid_t event_ptid = target->wait (ptid, status, options);

For a multi-threaded process "top_target" *should* point to
aix_thread_ops, which is achieved by this call in pd_enable:
  current_inferior ()->push_target (&aix_thread_ops);

However, note that this is applied only to *one* inferior.
You actually need to do this for *all* new inferiors as soon
as they are detected to become multi-threaded.

This does not happen because aix-thread.c currently has a static
global pd_able variable that applies to GDB as a whole.  Back in
the days where this was introduced, that was probably correct
since a single GDB session could only debug one single inferior
back then.  But for multiple inferiors, any of which can be
multi-threaded, this does not work.


I think you should first of all work on fixing this, and then
go back to validating your test scenarios without any of the
other changes - many of those likely will no longer be
necessary then.


Bye,
Ulrich