This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: RE: New to multi/embeddedICE
- To: David Airlie <David dot Airlie at parthus dot com>
- Subject: RE: [ECOS] RE: New to multi/embeddedICE
- From: "Kovitz, Paul" <kovitzP at sharpsec dot com>
- Date: Thu, 15 Feb 2001 12:57:35 -0500
- Cc: ecos-discuss at sources dot redhat dot com
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.
========================