[PATCH] fix spurious FAIL in py-inferior.exp (x86-solaris)

[PATCH] fix spurious FAIL in py-inferior.exp (x86-solaris)

[Joel Brobecker]

The inferior is single-threaded, but on x86-solaris, GDB says
that the program has two entries in the thread list:

    (gdb) info threads
      Id   Target Id         Frame
    * 2    Thread 1 (LWP 1)  f2 (a=1) at /[...]/py-inferior.c:20
      1    LWP    1          f2 (a=1) at /[...]/py-inferior.c:20

As a result, the test that prints the list of threads trips
because the expected output assumes only one thread.

The regular expression I used to match is a little complicated because
of the case where there is only one element -vs- the case where there
is more than one.  In the first case, the last element is followed by
a comma.  In the second case, it's not.  I tried to make it easier
to read by using a variable that factorizes the expression matching
a thread object, as well as makes it shorter and easier to read.

gdb/testsuite/ChangeLog:

        * gdb.python/py-inferior.exp: Adjust expected output of
        test printing the list of threads as seen by Python, to
        allow the list to contain more than 1 thread.

Tested on x86-solaris and x86_64-linux.

---
 gdb/testsuite/gdb.python/py-inferior.exp |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/gdb/testsuite/gdb.python/py-inferior.exp b/gdb/testsuite/gdb.python/py-inferior.exp
index 138c0fb..07c7801 100644
--- a/gdb/testsuite/gdb.python/py-inferior.exp
+++ b/gdb/testsuite/gdb.python/py-inferior.exp
@@ -64,7 +64,12 @@ gdb_test "python print 'result =', i0 == inferiors\[0\]" " = True" "test equalit
 gdb_test "python print 'result =', i0.num" " = \[0-9\]+" "test Inferior.num"
 gdb_test "python print 'result =', i0.pid" " = \[0-9\]+" "test Inferior.pid"
 gdb_test "python print 'result =', i0.was_attached" " = False" "test Inferior.was_attached"
-gdb_test "python print i0.threads ()" "\\(<gdb.InferiorThread object at 0x\[\[:xdigit:\]\]+>,\\)" "test Inferior.threads"
+# Print the list of threads in inferior 0.  Althought this inferior
+# does not use threads, the list of threads may in fact show more
+# than 1 thread.  We've seen this on x86-solaris where "info threads"
+# shows 1 thread and 1 LWP.
+set thread_re "<gdb.InferiorThread object at 0x\[\[:xdigit:\]\]+>"
+gdb_test "python print i0.threads ()" "\\(${thread_re}((, ${thread_re})*|,)\\)" "test Inferior.threads"
 
 # Test memory read and write operations.
 
-- 
1.7.1

Re: [PATCH] fix spurious FAIL in py-inferior.exp (x86-solaris)

[Mark Kettenis]

> From: Joel Brobecker <brobecker@adacore.com>
> Date: Fri,  4 Mar 2011 15:31:08 +0400
> 
> The inferior is single-threaded, but on x86-solaris, GDB says
> that the program has two entries in the thread list:
> 
>     (gdb) info threads
>       Id   Target Id         Frame
>     * 2    Thread 1 (LWP 1)  f2 (a=1) at /[...]/py-inferior.c:20
>       1    LWP    1          f2 (a=1) at /[...]/py-inferior.c:20
> 
> As a result, the test that prints the list of threads trips
> because the expected output assumes only one thread.

That's a bug in the Solaris thread support. So...

> The regular expression I used to match is a little complicated because
> of the case where there is only one element -vs- the case where there
> is more than one.  In the first case, the last element is followed by
> a comma.  In the second case, it's not.  I tried to make it easier
> to read by using a variable that factorizes the expression matching
> a thread object, as well as makes it shorter and easier to read.

...I think you should not adjust the testsuite for this.

Re: [PATCH] fix spurious FAIL in py-inferior.exp (x86-solaris)

[Pedro Alves]

On Friday 04 March 2011 12:18:01, Mark Kettenis wrote:
> That's a bug in the Solaris thread support. So...

It's by design.   Consequence of the M:N support, IIRC.
(I didn't design it!)

-- 
Pedro Alves

Re: [PATCH] fix spurious FAIL in py-inferior.exp (x86-solaris)

[Joel Brobecker]

> On Friday 04 March 2011 12:18:01, Mark Kettenis wrote:
> > That's a bug in the Solaris thread support. So...
> 
> It's by design.   Consequence of the M:N support, IIRC.
> (I didn't design it!)

So, are we OK with this patch?

Thanks,
-- 
Joel

Re: [PATCH] fix spurious FAIL in py-inferior.exp (x86-solaris)

[Jan Kratochvil]

On Mon, 07 Mar 2011 05:39:23 +0100, Joel Brobecker wrote:
> > On Friday 04 March 2011 12:18:01, Mark Kettenis wrote:
> > > That's a bug in the Solaris thread support. So...
> > 
> > It's by design.   Consequence of the M:N support, IIRC.
> > (I didn't design it!)
> 
> So, are we OK with this patch?

I do not have a fix but there seems to me mistaken LWP<->PID, each thread gets
duplicated once as {PID, 0, ID} and once as {PID, ID, 0}.

(gdb) info threads 
  Id   Target Id         Frame 
  10   Thread 4 (LWP 4)  start3 (arg=0x0) at threadit.c:9
  9    Thread 3 (LWP 3)  start2 (arg=0x0) at threadit.c:8
  8    Thread 2 (LWP 2)  start1 (arg=0x0) at threadit.c:7
* 7    Thread 5 (LWP 5)  start4 (arg=0x0) at threadit.c:10
  6    LWP    5          start4 (arg=0x0) at threadit.c:10
  5    LWP    4          start3 (arg=0x0) at threadit.c:9
  4    LWP    3          start2 (arg=0x0) at threadit.c:8
  3    LWP    2          start1 (arg=0x0) at threadit.c:7
  2    Thread 1 (LWP 1)  0xfef022f5 in __lwp_wait () from /lib/libc.so.1
  1    LWP    1          0xfef022f5 in __lwp_wait () from /lib/libc.so.1


Regards,
Jan

Re: [PATCH] fix spurious FAIL in py-inferior.exp (x86-solaris)

[Mark Kettenis]

> Date: Mon, 7 Mar 2011 08:39:23 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> 
> > On Friday 04 March 2011 12:18:01, Mark Kettenis wrote:
> > > That's a bug in the Solaris thread support. So...
> > 
> > It's by design.   Consequence of the M:N support, IIRC.
> > (I didn't design it!)
> 
> So, are we OK with this patch?

Not really.  Solaris has not been using a M:N for quite some time now.
And I think GDB should present threads in a consistent way.

Re: [PATCH] fix spurious FAIL in py-inferior.exp (x86-solaris)

[Joel Brobecker]

> Not really.  Solaris has not been using a M:N for quite some time now.
> And I think GDB should present threads in a consistent way.

Alright. For now, the patch is withdrawn.  If people are interested,
I can turn this into a KFAIL...

-- 
Joel

Re: [PATCH] fix spurious FAIL in py-inferior.exp (x86-solaris)

[Pedro Alves]

On Monday 07 March 2011 05:04:45, Jan Kratochvil wrote:
> I do not have a fix but there seems to me mistaken LWP<->PID, each thread gets
> duplicated once as {PID, 0, ID} and once as {PID, ID, 0}.
> 
> (gdb) info threads 
>   Id   Target Id         Frame 
>   10   Thread 4 (LWP 4)  start3 (arg=0x0) at threadit.c:9
>   9    Thread 3 (LWP 3)  start2 (arg=0x0) at threadit.c:8
>   8    Thread 2 (LWP 2)  start1 (arg=0x0) at threadit.c:7
> * 7    Thread 5 (LWP 5)  start4 (arg=0x0) at threadit.c:10
>   6    LWP    5          start4 (arg=0x0) at threadit.c:10
>   5    LWP    4          start3 (arg=0x0) at threadit.c:9
>   4    LWP    3          start2 (arg=0x0) at threadit.c:8
>   3    LWP    2          start1 (arg=0x0) at threadit.c:7
>   2    Thread 1 (LWP 1)  0xfef022f5 in __lwp_wait () from /lib/libc.so.1
>   1    LWP    1          0xfef022f5 in __lwp_wait () from /lib/libc.so.1

It's not a simple "mistake".  Notice how the ids of LWPs are
aligned to the ids of threads.  This was not a coincidence, it
was done on purpose.  This was how solaris thread support
always behaved, up until the pthreads support got completely
broken circa gdb 6.3 and then I restored it a couple of years
ago (see "Modernize solaris threads support" thread).

From Solaris 2 to 8, the default user thread library
used an M:N model.  On v8 a 1:1 implementation appeared,
but it was not made the default (you can select it
at link time).  Solaris 9 switched to 1:1 completely.

Ref: <http://wwws.sun.com/software/whitepapers/solaris9/multithread.pdf>

The original author seems to have thought best to
just always expose everything.  I don't know what's
the use case that gets broken if we don't expose
lwps when the threading library is active.  Maybe
something around inactive threads.  Most likely nothing.

-- 
Pedro Alves

Re: [PATCH] fix spurious FAIL in py-inferior.exp (x86-solaris)

[Pedro Alves]

On Monday 07 March 2011 09:20:43, Mark Kettenis wrote:
> > Date: Mon, 7 Mar 2011 08:39:23 +0400
> > From: Joel Brobecker <brobecker@adacore.com>
> > 
> > > On Friday 04 March 2011 12:18:01, Mark Kettenis wrote:
> > > > That's a bug in the Solaris thread support. So...
> > > 
> > > It's by design.   Consequence of the M:N support, IIRC.
> > > (I didn't design it!)
> > 
> > So, are we OK with this patch?
> 
> Not really.  Solaris has not been using a M:N for quite some time now.

Up until v8.  I thought we still supported that version.

> And I think GDB should present threads in a consistent way.

Indeed.  It raises the question of what is a "thread" from
gdb's perspective.  In my mind, it's the "currently
active/visible sceduling entity granularity".  dbx has
separate commands to list threads and lwps.  Maybe gdb should
too.  Bonus points if that is implemented with a proper
model that works against remote targets too.

-- 
Pedro Alves