From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23378 invoked by alias); 24 Oct 2003 01:49:28 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 23335 invoked from network); 24 Oct 2003 01:49:23 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 24 Oct 2003 01:49:23 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1ACr4t-0004gE-0B for ; Thu, 23 Oct 2003 21:49:23 -0400 Date: Fri, 24 Oct 2003 01:49:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [doco/threads] document internal thread signals on gnu/linux Message-ID: <20031024014922.GA17970@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <200310240123.h9O1N3iw010450@duracef.shout.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310240123.h9O1N3iw010450@duracef.shout.net> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00717.txt.bz2 On Thu, Oct 23, 2003 at 09:23:03PM -0400, Michael Elizabeth Chastain wrote: > This patch adds some doco about the existence and side effects > of thread internal signals in GNU/Linux systems. > > It should be, errr, self-documenting. If you can't figure out > what I'm talking about, then I need to rewrite this. > > I'm motivated to write this because one of our test programs actually > has a coding error in it, and this doco explains why the test program is > badly written and what happens when such a program is run under gdb. > > I'm looking for two kinds of comments: (1) is the content okay, > and (2) is the formatting okay. Close, but not quite. It's not extra signals that are the problem. The thread library (nowadays!) generates no more signals under GDB than otherwise, but it does generate a lot of signals. GDB knows how to ignore them. However, at some events the thread library calls a function where GDB puts a breakpoint. This causes GDB to stop all threads. Gdbserver does not suffer from this problem with such severity. I hope to free GDB from it eventually also, but the internals have a long way to go first. It can still happen if you stop the program for another reason, of course, like a normal breakpoint. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer