This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: arm-elf-gcc Debug info


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]