Re: [RFA/commit] Add support for DEC threads on alpha-osf

[Pedro Alves <pedro@codesourcery.com>]

On Tuesday 07 October 2008 14:03:22, Joel Brobecker wrote:
> Pedro, is there something I should be doing for the always-a-thread
> thing? 

Hmmm, procfs.c.  It looks weird that LWP 3 and the main process are
the same thing.  If they are the same, and I haven't messed something up,
you should only see one of them.  IIRC, I don't get that on solaris.

> I tested with a program that doesn't use threads, and the 
> good news is that I do see a "process" thread. Perhaps that was
> thanks to you.  

If there are no other LWPs, then yes, I made that change.  Before my
changes, if there were other LWPs in the process, then you'd've
already see the "process" thread, as it was added to the thread list
as soon as we would detect a new LWP.  After my changes, you get
that "process" even if there are no other LWPs other than the
main process in the inferior.

> On the other hand, I still see that process thread 
> when debugging programs that use threads, and I wonder if this is
> a problem or not.

So, from this info threads output:

> After the patch, the real threads now start appearing:
> 
>     (gdb) info threads
>       7 LWP 3  task_switch.break_me () at task_switch.adb:43
>       6 LWP 9  0x0000000000000000 in ?? ()
>       5 LWP 8  0x00000300000408e8 in __nxm_thread_block ()
>        from /usr/shlib/libpthread.so
>     * 4 Thread 3  task_switch.break_me () at task_switch.adb:43
>       3 Thread 2  0x000003000004067c in __hstTransferRegistersPC ()
>        from /usr/shlib/libpthread.so
>       2 Thread 1  0x000003000004067c in __hstTransferRegistersPC ()
>        from /usr/shlib/libpthread.so
>       1 process 269190  task_switch.break_me () at task_switch.adb:43

... this is an M:N configuration?  It looks like it, because threads 2,3,4 were
added before the lwps 5,6,7, and the threads 2,3 show a different
frame from lwps 5,6.  In that case, it seems fine to me to show them,
assuming the user stepping an LWP doesn't make GDB do something
dump regarding GDB's stepping state of the user threads.

Or, are all user threads scheduled on the main process/lwp ?  Then what
the heck is thread 5 blocked on ?  :-)

Or, if this is user threads/LWPs are 1:1 then something looks broken.  If
that's the case, my opinion would be that it would be best to only
show the user threads.

Anyway, these are all dumb question that came to mind, because
I miss a description of DEC's thread model at the top of
dec-thread.c.  Something akin to sol-thread.c, but needn't
be so extensive.  :-)

-- 
Pedro Alves