Debugging with Tornado 2.2 and no "-g" switch crashes debugger, or debugger doesn't work at all. - VxWorks

This is a discussion on Debugging with Tornado 2.2 and no "-g" switch crashes debugger, or debugger doesn't work at all. - VxWorks ; Hello, I've just encountered some strange problems debugging code with Tornado 2.2 for the first time. We have used Tornado 2.0 for the past few years and haven't seen problems similar to these before. A have a simple application which ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Debugging with Tornado 2.2 and no "-g" switch crashes debugger, or debugger doesn't work at all.

  1. Debugging with Tornado 2.2 and no "-g" switch crashes debugger, or debugger doesn't work at all.

    Hello,

    I've just encountered some strange problems debugging code with Tornado 2.2
    for the first time. We have used Tornado 2.0 for the past few years and
    haven't seen problems similar to these before.

    A have a simple application which is linked against a couple of in-house
    libraries, and I'm attempting to debug that application. This is all noddy
    stuff which I'd expect to work straight away.

    If I build my 2 libraries with debug info (-g switch), then build my
    application with -g and link against the libraries, I can debug as I expect,
    and everything just works.

    However, if the libraries are not built with the -g switch, I experience
    some strange behaviour when debugging the application, which is still built
    with -g. In particular, when I am stepping through my application in the
    source view, and I attempt to step over a function which is contained within
    one of my libraries, the debugger (cgdbppc.exe) crashes. Up to this point, I
    could quite happily debug code from the application, as it was compiled with
    the -g switch enabled.

    Does anyone have any ideas what might be causing this. I'd expect the
    debugger to step over a function for which it did not have debug info, and
    even to be able to step into it in the "assembler" view. There must be
    something basic that I've missed.

    The application and libraries are built with the same compiler, options etc,
    apart from the -g switch.

    While I'm at it, I have another question. I typically load code to my target
    from flash memory, or from an application on a networked (non Tornado) PC
    using the memDevCreate() and loadModule() functions, thereby bypassing the
    Tornado host tools / target server etc. This is primarily to ease
    development of a multi-cpu system.

    However, if I attempt to debug code which has been downloaded this way, the
    debugger hangs up (especially when a backtrace is being displayed), or
    crashes as described above (even when the application and libraries are all
    built with -g). I'm guessing that this is because the debugger is trying to
    access the module which has been loaded to get access to the debug info
    contained within.

    Googling suggests that the likely cause is a lack of symbol table
    synchronisation. However, I do have symbol table synchronisation built into
    the VxWorks image, and it is enabled in the target server configuration.
    "lkup" and "@lkup" both return valid symbol information for the module, yet
    the debugger still seems to hang up.

    Is there any way around this problem, other than always loading code through
    a target server when it is to be debugged?

    Thanks in advance.

    --
    Craig Wilkie



  2. Re: Debugging with Tornado 2.2 and no "-g" switch crashes debugger, or debugger doesn't work at all.

    Sorry to reply to my own post, but I should've mentioned some more details.

    I'm using the GNU compiler toolchain, and a PowerPC (7447 CPU) target.
    Application is built for the 603 PPC architecture.

    Cheers,

    Craig



  3. Re: Debugging with Tornado 2.2 and no "-g" switch crashes debugger, or debugger doesn't work at all.

    Craig:

    I've seen the problem you've mentioned myself - even stepping into "non
    -g" code made the debugger crash or just hung the target - I think
    what I ended up doing is not directly stepping over the "non -g" code -
    I moved the cursor futher down in the file and did a run-to-cursor. I
    didn't persue it with WRS - maybe they've got something online.

    I'm not clear on your load method, but I think it's equivalent to
    loading from the target shell - ie ld < loadfile.o. I run that way all
    the time with symsynch turned on and have had no major problems woth
    T221.

    I use -mcpu=604 for a 7447 target.

    Good luck,
    lc


+ Reply to Thread