From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32437 invoked by alias); 7 Oct 2008 14:08:39 -0000 Received: (qmail 32402 invoked by uid 22791); 7 Oct 2008 14:08:38 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 07 Oct 2008 14:08:00 +0000 Received: (qmail 15922 invoked from network); 7 Oct 2008 14:07:58 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 7 Oct 2008 14:07:58 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFA/commit] Add support for DEC threads on alpha-osf Date: Tue, 07 Oct 2008 14:08:00 -0000 User-Agent: KMail/1.9.9 Cc: Joel Brobecker References: <20081007130322.GD28143@adacore.com> In-Reply-To: <20081007130322.GD28143@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200810071508.32985.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-10/txt/msg00207.txt.bz2 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?=20 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=20 > good news is that I do see a "process" thread. Perhaps that was > thanks to you. =C2=A0 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=20 > 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: >=20 > (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. :-) --=20 Pedro Alves