From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6736 invoked by alias); 12 Jul 2004 11:11:03 -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 6721 invoked from network); 12 Jul 2004 11:11:00 -0000 Received: from unknown (HELO mail.pune.nevisnetworks.com) (203.124.166.179) by sourceware.org with SMTP; 12 Jul 2004 11:11:00 -0000 Received: from nevis_pune_xchg.pune.nevisnetworks.com (nevis_pune_xchg.pune.nevisnetworks.com [192.168.2.7]) by mail.pune.nevisnetworks.com (8.12.8/8.12.8) with ESMTP id i6CB07EH001299 for ; Mon, 12 Jul 2004 16:30:07 +0530 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Adding backtrace to an arm-based on-target debugger Date: Mon, 12 Jul 2004 11:11:00 -0000 Message-ID: <36993D449C7FA647BF43568E0793AB3E4C87B2@nevis_pune_xchg.pune.nevisnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Atul Talesara" To: X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) X-SW-Source: 2004-07/txt/msg00105.txt.bz2 >Hi Atul, > >The type of applications I am trying to debug using my arm-based stub >are compiled with arm-elf-gcc. But these applications make certain >system calls to an underlying module, which happens to be compiled >using armcc. > >Another important point is that the application(compiled in >arm-elf-gcc) and the underlying module(compiled in armcc) make use of >the same stack. > >So, when I do a "bt" on the gdb prompt, the gdb has to parse the stack >that contains symbols of both the arm-elf-gcc compiled code and the >arm-cc compiled code. Can the gdb do that? Hello Nagender, I'm not sure if GDB can manage if both the compilers have different "stack frame" formats. Don't know if your compilers generate incompatible stack frames. > >Regarding the gdb documentation, I find only description of the >symbols(c, n, g etc) that are used but not the actual protocol or the >actual handshaking mechanism, that is, I want to know what happens >after you do a bt, s or a c on the gdb prompt.=20 [1] The best ways is to see one of the standard stubs in action with remote debug on: (gdb) set debug remote 1 >Is the series of >requests that the gdb makes to the stub documented? Not exactly, but they should be pretty much standard for most of arch. For Ex.: When a breakpoint is reported to GDB by the stub, it take PC to find corresponding source line, SP to find argument values, etc. The later results in a few mem reads in the stack area. Looking at the packets [1] and the GDB RSP document [2] you should be able to figure out very easily all you want. [2] http://www.cs.odu.edu/~public/gdbdocs/gdb_32.html -regards, Atul T. ------------------------------------------------------------=20 A computer without Windows is like a fish without a bicycle! From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19018 invoked by alias); 12 Jul 2004 11:33:11 -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 18998 invoked from network); 12 Jul 2004 11:33:08 -0000 Received: from unknown (HELO mail.pune.nevisnetworks.com) (203.124.166.179) by sourceware.org with SMTP; 12 Jul 2004 11:33:08 -0000 Received: from nevis_pune_xchg.pune.nevisnetworks.com (nevis_pune_xchg.pune.nevisnetworks.com [192.168.2.7]) by mail.pune.nevisnetworks.com (8.12.8/8.12.8) with ESMTP id i6CBMFEH002221 for ; Mon, 12 Jul 2004 16:52:16 +0530 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Adding backtrace to an arm-based on-target debugger Date: Mon, 12 Jul 2004 13:56:00 -0000 Message-ID: <36993D449C7FA647BF43568E0793AB3E4C87B2@nevis_pune_xchg.pune.nevisnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Atul Talesara" To: X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) X-SW-Source: 2004-07/txt/msg00106.txt.bz2 Message-ID: <20040712135600.ONYhuBaC2RBx_72MLCv5TaE-YZ9GvQ43xyBkEOserqs@z> >Hi Atul, > >The type of applications I am trying to debug using my arm-based stub >are compiled with arm-elf-gcc. But these applications make certain >system calls to an underlying module, which happens to be compiled >using armcc. > >Another important point is that the application(compiled in >arm-elf-gcc) and the underlying module(compiled in armcc) make use of >the same stack. > >So, when I do a "bt" on the gdb prompt, the gdb has to parse the stack >that contains symbols of both the arm-elf-gcc compiled code and the >arm-cc compiled code. Can the gdb do that? Hello Nagender, I'm not sure if GDB can manage if both the compilers have different "stack frame" formats. Don't know if your compilers generate incompatible stack frames. > >Regarding the gdb documentation, I find only description of the >symbols(c, n, g etc) that are used but not the actual protocol or the >actual handshaking mechanism, that is, I want to know what happens >after you do a bt, s or a c on the gdb prompt.=20 [1] The best ways is to see one of the standard stubs in action with remote debug on: (gdb) set debug remote 1 >Is the series of >requests that the gdb makes to the stub documented? Not exactly, but they should be pretty much standard for most of arch. For Ex.: When a breakpoint is reported to GDB by the stub, it take PC to find corresponding source line, SP to find argument values, etc. The later results in a few mem reads in the stack area. Looking at the packets [1] and the GDB RSP document [2] you should be able to figure out very easily all you want. [2] http://www.cs.odu.edu/~public/gdbdocs/gdb_32.html -regards, Atul T. ------------------------------------------------------------=20 A computer without Windows is like a fish without a bicycle!