From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1925 invoked by alias); 18 Sep 2006 08:21:53 -0000 Received: (qmail 1916 invoked by uid 22791); 18 Sep 2006 08:21:51 -0000 X-Spam-Check-By: sourceware.org Received: from fra-del-02.spheriq.net (HELO fra-del-02.spheriq.net) (195.46.51.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Sep 2006 08:21:49 +0000 Received: from fra-out-02.spheriq.net (fra-out-02.spheriq.net [195.46.51.130]) by fra-del-02.spheriq.net with ESMTP id k8I8KEXc009056 for ; Mon, 18 Sep 2006 08:20:40 GMT Received: from fra-cus-01.spheriq.net (fra-cus-01.spheriq.net [195.46.51.37]) by fra-out-02.spheriq.net with ESMTP id k8I8KCiX008154 for ; Mon, 18 Sep 2006 08:20:13 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-01.spheriq.net with ESMTP id k8I8K7Mf028166 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 18 Sep 2006 08:20:11 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id BA945DA46; Mon, 18 Sep 2006 08:20:04 +0000 (GMT) Received: from mail1.cro.st.com (mail1.cro.st.com [164.129.40.131]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id D97AA47322; Mon, 18 Sep 2006 08:20:02 +0000 (GMT) Received: from st.com (crx1177.cro.st.com [164.129.47.77]) by mail1.cro.st.com (MOS 3.5.8-GR) with ESMTP id CIL67031 (AUTH "denis pilat"); Mon, 18 Sep 2006 10:20:00 +0200 (CEST) Message-ID: <450E56B0.806@st.com> Date: Mon, 18 Sep 2006 08:21:00 -0000 From: Denis PILAT User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches Subject: info thread Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-09/txt/msg00095.txt.bz2 Daniel, I'd like your opinion about a feature that we need to implement in gdb. We'd like to choose the solution that has the best chance to be accepted and integrated in GDB. As you may know, Eclipse is using "info threads" command to get thread Ids. The problem is that some part of this command is not used by Eclipse and can take a lot of time to execute when the debugger is remotely connected to a board. In our case we have a 100 threads application and the info threads takes a lot of time to execute, and in Eclipse this command is run each time the user push the "next" button, which leads to a non usable graphical interface. The stack frame information is not used at all by Eclipse and removing this part saves 70% of the execution time in our case. Eclipse used the thread list IDs and the extra information which are target specific (usually we get thread names in these information but it can be whatever the targets puts) The solutions we thought are the following: Sol 1 - developping a new MI command that gives the above target extra information only (ie -thread-list-extra-info) of implementing a non-implemented one with a parameter. I see in the doc that -thread-list-all-threads is not specified for instance. Then we need to modify Eclipse so that it uses MI command "-thread-list-ids" plus this command to get all he needs. This can be an Eclipse contribution as well, I need to ask to Eclipse maintainer as well. Sol 2 - a parameter to the "info thread" CLI command that ask gdb to not print stack frame information but only thread IDs lists and extra_info. (ie info thread nostackframe) Sol 3 - a new gdb env variable that do the same as the above parameter. What is your opinion about that ? Which solution could be adopted ? Regards Denis PILAT