From: "Atul Talesara" <atul.talesara@nevisnetworks.com>
To: <gdb@sources.redhat.com>
Subject: RE: Adding backtrace to an arm-based on-target debugger
Date: Mon, 12 Jul 2004 11:11:00 -0000 [thread overview]
Message-ID: <36993D449C7FA647BF43568E0793AB3E4C87B2@nevis_pune_xchg.pune.nevisnetworks.com> (raw)
>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.
[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.
------------------------------------------------------------
A computer without Windows is like a fish without a bicycle!
WARNING: multiple messages have this Message-ID
From: "Atul Talesara" <atul.talesara@nevisnetworks.com>
To: <gdb@sources.redhat.com>
Subject: RE: Adding backtrace to an arm-based on-target debugger
Date: Mon, 12 Jul 2004 13:56:00 -0000 [thread overview]
Message-ID: <36993D449C7FA647BF43568E0793AB3E4C87B2@nevis_pune_xchg.pune.nevisnetworks.com> (raw)
Message-ID: <20040712135600.ONYhuBaC2RBx_72MLCv5TaE-YZ9GvQ43xyBkEOserqs@z> (raw)
>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.
[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.
------------------------------------------------------------
A computer without Windows is like a fish without a bicycle!
next reply other threads:[~2004-07-12 11:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-12 11:11 Atul Talesara [this message]
2004-07-12 13:56 ` Atul Talesara
2004-07-27 21:48 ` using gdb for code compiled with armcc Nagender Telkar
[not found] <36993D449C7FA647BF43568E0793AB3E8C79F9@nevis_pune_xchg.pune.nevisnetworks.com>
2004-07-09 0:59 ` Adding backtrace to an arm-based on-target debugger Nagender Telkar
-- strict thread matches above, loose matches on Subject: below --
2004-07-08 5:26 Atul Talesara
2004-07-05 0:40 Nagender Telkar
2004-07-05 4:35 ` Ramana Radhakrishnan
2004-07-07 20:25 ` Nagender Telkar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=36993D449C7FA647BF43568E0793AB3E4C87B2@nevis_pune_xchg.pune.nevisnetworks.com \
--to=atul.talesara@nevisnetworks.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).