Dave wrote:
__________________________
	I think by harsh you mean it can debug elf images without debugging
	information .. I've managed this on occasion with the 2.51 tools,
using
	stripped binaries .. which is not a method of debugging I would
recommend
	to anyone ...

	I bought a Jeeni, an although not the best (still haven't got it to
figure
	out eCos threads), it has helped in a lot of cases ...

	Dave.
	__________________

We use EPI JEENI here, too. However, the JEENI does not fully support the
ARM 920 cores yet, a problem considering Sharp's new licensing of the
InfoStream IP from Parthus (in case you are interested, check out
http://www.sharpsma.com/news/press/parthus.htm and
http://www.parthus.com/platforms/parthus_infostream/infostream_platform.html
. Please let me know (gently; I am new to this list) if posted
product-related links to this list is a no-no. If it is, I won't do it
again).

This is what I got from ARM about their support of gcc and binutils:

	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.

	========================