VisionIce, symbols, and source level debugging - VxWorks

This is a discussion on VisionIce, symbols, and source level debugging - VxWorks ; I have an older VisionICE (from the days when it was still an EST product) that I use with VisionClick 7.0 (VC7) to debug code for a proprietary PPC860T target built using Tornado2.2, VxWorks5.5.1, and the GNU toolset that is ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: VisionIce, symbols, and source level debugging

  1. VisionIce, symbols, and source level debugging

    I have an older VisionICE (from the days when it was still an EST product)
    that I use with VisionClick 7.0 (VC7) to debug code for a proprietary PPC860T
    target built using Tornado2.2, VxWorks5.5.1, and the GNU toolset that is
    supplied by Wind River.

    I've dusted these tools off to do some BSP maintenance and again learned
    that I have never been able to get VC7 source level debugging to work. I
    invoke the -g and -O0 compier flags in my BSP makefile using the ADDED_CFLAGS
    macro and I see these in the build output, but the VC7 binary and symbol
    conversion utility still issues the warning "no debug information found."
    Then, when loading symbols in VC7 using either "Initialize All" or "Read A
    Symbol File", no symbols appear in the Symbol Explorer and the source window
    displays only disassembled instructions.

    I have discovered three oddities while trying to get this working.

    1) Despite failing to find debug info, VC7 seems able to find the address of
    my reset symbol regardless of whether I invoke the ADDED_CFLAGS.

    2) The VC7 convert utility creates the files bootrom.ab and bootrom.abx.
    If I delete bootrom.abx before loading symbols in VC7, then VC7's symbol
    explorer shows global symbols but no modules or functions, but still
    shows only disassemble instruction in the source window. Again, it does
    this regardless of whether I invoke the ADDED_CFLAGS.

    3) I cannot remember the third oddity.

    I found an obscure reference on the web from 2000 that there may be an issue
    with the convert utility and output from the GNU tools. This is at
    http://ozlabs.org/pipermail/linuxppc...er/002200.html

    Does anybody know anything about this?

    --
    ================================================== ======================
    Michael Kesti | "And like, one and one don't make
    | two, one and one make one."
    mrkesti at hotmail dot com | - The Who, Bargain

  2. Re: VisionIce, symbols, and source level debugging

    I made some progress on this today and discovered that I can get source
    level debugging for *.c files, but not *.s files, when ADDED_CFLAGS is
    defiend as "-gstabs" rather than "-g -O0". I most need source level
    debugging for rominit.s and sysALib.s, however, so I'm still not where
    I need to be!

    The build output shows that the "-gstabs" option is being passed to ccppc
    for both the *.c and *.s files. The only build option differences between
    these types is that *.s files get three additional options. These are:

    -P
    tells the preprocessor not to generate `#line' directives
    -xassemble-with-cpp option
    explicitly specifies source file language
    -o
    explicitly specifies the output file name

    Executing objdumpppc with the -g option on romInit. and sysALib.o
    indicates that these object files indeed contain no debug info.

    I experimented with a build script so that I could conveniently change
    options without editing any of the many make directive files WR provides
    but failed to find any combination of options that built *.s files with
    debug info.

    Can it be that GNU ccppc just won't generate debug info when building
    assembler source files?

    --
    ================================================== ======================
    Michael Kesti | "And like, one and one don't make
    | two, one and one make one."
    mrkesti at hotmail dot com | - The Who, Bargain

+ Reply to Thread