From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16303 invoked by alias); 6 Aug 2004 13:28:09 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 16293 invoked from network); 6 Aug 2004 13:28:08 -0000 Received: from unknown (HELO v07216.home.net.pl) (212.85.125.104) by sourceware.org with SMTP; 6 Aug 2004 13:28:08 -0000 Received: from 62.233.217.1 (HELO sysc1300) (sysmikro@home@62.233.217.1) by matrix15.home.net.pl with SMTP; 6 Aug 2004 13:28:06 -0000 Message-ID: <001f01c47bb8$910cca70$21ffffc0@sysc1300> From: =?iso-8859-2?Q?Krzysztof_B=B3aszkowski?= To: Subject: Fw: GDB-6.2 Date: Fri, 06 Aug 2004 13:28:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-SW-Source: 2004-08/txt/msg00101.txt.bz2 ----- Original Message ----- From: Krzysztof B³aszkowski To: gdb@sources.redhat.com Sent: Friday, August 06, 2004 3:21 PM Subject: GDB-6.2 Hi all, At first I would like to say that this is a good job. I am really impressed. I've been developing jtag adapter for arm7tdmi architecture with linux (uClinux) task support and a tcp RSP protocol interface for a some period of time so I have seen the 5.3 and 6.0 versions. The new one (6.2) relocates properly the static local variables from .data and .bss sections. The older versions used a pointers which were 4 byte less than the real one. I have tested the "add-symbol-file" command which is very essential to me. Now I can see also a thread list when frame pointer is NULL (a r11) so there is no annoying "No frame" message. Also "bt" works perfectly. I can select any kernel (or userland) thread and see its backtrace. I have observed that the 6.2 gdb is able to select a thread for execution only for first time. I mean a first "thread _number_". The succesive "thread" commands changes registers obviously but when I issue a "c" and system stops at breakpoint in different task then I try to execute step by step other task (the current - I issue "i thr" and "thr" with new ID) than the selected one for first time, the gdb takes incorrect address for breakpoint. It takes an address from the first selected task not the current one I would like to execute. Any ideas ? I have to quit gdb at present and run it again to change the task for execution. I have got a question regarding to the task with pid number 0. Why is that task skipped by gdb ? Should my adapter add a 1e6 to the pid of this task ? Can someone explain me the uniqueness of the init task? (after it has replaced itself with an init from root file system). I have discovered that it does not store pt_regs as other userland tasks so it must use a context_save_struct as other kernel tasks I guess. The init task has also a mm. I used a mm pointer to distinguish a userland task and a kernel task. That way fails for an init task. Is there a better way ? Best regards, Krzysztof Blaszkowski Systemy mikroprocesorowe Krzysztof Blaszkowski Santocka 44 71-071 Szczecin, Poland http://www.sysmikro.com.pl