From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31718 invoked by alias); 5 Jun 2009 22:22:24 -0000 Received: (qmail 31708 invoked by uid 22791); 5 Jun 2009 22:22:24 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 05 Jun 2009 22:22:18 +0000 Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id n55MMGvU020025 for ; Fri, 5 Jun 2009 15:22:16 -0700 Received: from localhost (ppluzhnikov.mtv.corp.google.com [172.18.118.92]) by wpaz21.hot.corp.google.com with ESMTP id n55MMELN025880; Fri, 5 Jun 2009 15:22:14 -0700 Received: by localhost (Postfix, from userid 74925) id 66E2976BC4; Fri, 5 Jun 2009 15:22:14 -0700 (PDT) To: gdb-patches@sourceware.org Cc: ppluzhnikov@google.com, dje@google.com Subject: [patch] Fix for gdb.threads/staticthreads.exp failure on Linux Message-Id: <20090605222214.66E2976BC4@localhost> Date: Fri, 05 Jun 2009 22:22:00 -0000 From: ppluzhnikov@google.com (Paul Pluzhnikov) 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: 2009-06/txt/msg00140.txt.bz2 Greetings, The following tests always fail for us: FAIL: gdb.threads/staticthreads.exp: running to main in runto FAIL: gdb.threads/staticthreads.exp: Continue to main's call of sem_post FAIL: gdb.threads/staticthreads.exp: handle SIG32 helps This is happening because when loading a statically-linked executable, gdb detects threads right away, but attempt to enumerate threads at that time fails, because "thread subsystem" in the inferior has not been initialized yet. This causes spurious error: [Thread debugging using libthread_db enabled] find_new_threads_callback: cannot get thread info: generic error and makes subsequent debugging impossible. Attached patch silently ignores such errors, and makes staticthreads PASS. Tested on Linux/x86_64. Ok to check in? Thanks, -- Paul Pluzhnikov 2009-06-05 Paul Pluzhnikov * linux-thread-db.c (thread_db_find_new_threads_silently): New function. (try_thread_db_load_1): Call it. Index: linux-thread-db.c =================================================================== RCS file: /cvs/src/src/gdb/linux-thread-db.c,v retrieving revision 1.60 diff -u -p -u -r1.60 linux-thread-db.c --- linux-thread-db.c 24 May 2009 21:06:53 -0000 1.60 +++ linux-thread-db.c 5 Jun 2009 22:01:37 -0000 @@ -588,6 +588,25 @@ enable_thread_event_reporting (void) } } +/* Same as thread_db_find_new_threads_1, but silently ignore errors. */ + +static void +thread_db_find_new_threads_silently (ptid_t ptid) +{ + volatile struct gdb_exception except; + + TRY_CATCH (except, RETURN_MASK_ERROR) + { + thread_db_find_new_threads_1 (ptid); + } + + if (except.reason < 0 && info_verbose) + { + exception_fprintf (gdb_stderr, except, + "Warning: thread_db_find_new_threads_silently: "); + } +} + /* Lookup a library in which given symbol resides. Note: this is looking in GDB process, not in the inferior. Returns library name, or NULL. */ @@ -705,7 +724,7 @@ try_thread_db_load_1 (struct thread_db_i push_target (&thread_db_ops); enable_thread_event_reporting (); - thread_db_find_new_threads_1 (inferior_ptid); + thread_db_find_new_threads_silently (inferior_ptid); return 1; }