arm-elf-gcc Debug info

[Vincent Rubiolo]

Hello Yadid,

You should give a look to the manuals given with the ADS under section "Changes 
between ADS 1.2 and 1.2." It gives info about the caveats between GNU and ADS 
compilers in terms of image loading.

Here is the corresponding part in case you cannot find your manual ;) I think 
you may find it interesting...

Regards,

Vincent


********************************************************
Improved support for debugging third party images:

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.

**************************************************




------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com