This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Alternative to debug eCos using Multi-ICE
- To: "Ecos-Discuss (E-mail)" <ecos-discuss at sources dot redhat dot com>
- Subject: [ECOS] Alternative to debug eCos using Multi-ICE
- From: Ho Shui Choy Stanley PS03B NCS <scho at ncs dot com dot sg>
- Date: Thu, 3 May 2001 10:56:35 +0800
Hi everybody,
Good news to those who want to have GNU gdb support Multi-ICE for ARM
processor. There is an alternative way.
Please see forwarded message.
I have tried and its working.
-----Original Message-----
From: Kwanghee Lee [mailto:Andy.Lee@arm.com]
Sent: Wednesday, May 02, 2001 19:47
To: scho@ncs.com.sg
Subject: Re: [Fwd: 07813: Multi-ICE support for GDB](32000)
Hi, Stanley
One thing I can highlight though is that in the latest version of the
ARM Developer Suite, ADS 1.1, it is now possible to load GNU generated
images into the ARM debugger - which does at least provide one possible
Multi-ICE debugging route for you. The following details are taken from the
ADS 1.1 Getting Started Manual:
========================
AXD can now load and, with limitations, debug ELF/DWARF images built with
the GNU toolchain. The following restrictions apply to using AXD with gcc
2.95.2 and binutils 2.10:
* Binutils does not set the ELF flag to indicate that an entry point has
been set. You must manually set the PC to the entry point for the image.
This is commonly 0x00008000 or 0x0.
* Binutils does not generate the ARM mapping symbols that distinguish
between ARM code ($a), Thumb code ($t), and data ($d). This means that:
-You must manually select the disassembly mode in the disassembly window.
-Interleaved source and code is not disassembled. It is treated as
word-sized data.
-You cannot single step, because AXD cannot determine whether to set an ARM
breakpoint or a Thumb breakpoint.
Note
You can manually set an ARM breakpoint, however the debugger requests that
you confirm the action because it interprets the code as being a literal
pool. You can manually add a mapping symbol to mark ARM or Thumb state code
by linking the following assembly language at the start of your image. If
you are using the ARM assembler:
CODE32 ; or CODE16 for Thumb
AREA ||.text||, CODE, READONLY
NOP
END
If you are using the GNU assembler:
.text
.type $a,function @ or $t for Thumb
$a:
nop
The mapping symbol is in effect for the rest of the image, or until another
mapping symbol is encountered. This provides a workaround for the
disassembly and stepping restrictions listed above for images that contain
only ARM code or only Thumb code. However, it means that literal pools are
not detected and are disassembled as code, instead of being displayed as
data.
* GCC does not generate call frame information. This means actions that
rely on knowing the stack frame layout do not work. Specifically:
-No stack backtrace is available. Only the current function is shown in the
stack backtrace.
-Step out does not work. Local variables and parameters are available in
the variable view, however you must step over the function prologue code
that sets up the stack frame before they show the correct values.
Line number information is available, so the source view correctly displays
the current source line.
========================
When the "Multi-ICE for gdb" files are released, this will be advertised on
the Cygnus/Red-Hat web pages, however I cannot say when this will be.
Regards,
Andy