Remote C++ program debugging on ARM9

Development Boards MicroMod
1

Hello,

I’ve got RDK Phytec LPC3250 board with installed gdbserver and laptop with Debian GNU/Linux, arm-linux-gnu-gdb and Eclipse with CDT.

When I try to debug, main function “steps” fine, step into functions works fine too. But when I try to step into string like “obj = new Object();”, Eclipse opens error tab with header

2 operator new() new

and content

Can't find a source file at "/home/usb10132/ct1/bin/targets/src/gcc-4.3.2/libstdc++-v3/libsupc++/new_op.cc" 
Locate the file or edit the source lookup path to include its location.

Looks like instead of entering Object constructor, debugger tries to find source of ‘new’ operator and fails.

Debugging with gdb only (without Eclipse) leads to same result (and it’s not surprising)

Here is my debugging setup steps:

  • - Board Phytec LPC3250
  • - install gdbserver using LTIB building system
  • - run debugging program using command ``` gdbserver 192.168.0.7:6280 ``` where 192.168.0.7 -- laptop ip-address, 6280 -- some not-reserved port.

    Output is following:

    Process m2b created; pid = 374
Listening on port 6280
  • - Debian GNU/Linux Laptop
  • - install Eclipse и CDT (last versions at the moment), LTIB building system from CVS, ARM debugger gdb-arm-linux-gnu_6.8-3_i386 from [http://www.emdebian.org/toolchains/pool/main/g/gdb/](http://www.emdebian.org/toolchains/pool/main/g/gdb/)
  • - at the Eclipse menu Run->Debug Configurations->Debugger do following:
  • - in the field Debugger select 'gdbserver debugger';
  • - at the tab Main in 'GDB debugger set path to installed ARM debugger '/usr/bin/arm-linux-gnu-gdb';
  • - at the tab Shared Libraries set path to shared libs of the board (mine is '/home/raydan/ltib/rootfs/lib', subdir of root FS mounted by NFS)
  • - at the tab Connection select TCP, set ip-address and port
    • If someone have experience of C++ remote debugging in the same situation, share please.

    –

    Best Regards,

    Dmitry Vinokurov

    2

    I’ve used C++ on an LPC2138, with JTAG and OpenOCD, and had no trouble stepping into objects constructed on the heap.

    What version of GCC are you using?

    3

    The constructor needs to be passed a this pointer, so new is executed before entering the constructor.

    4

    Just a possible hack that could fix your debugging problem:

    you could overload the global operator new

    void *operator new(size_t size) throw()
{
    return malloc(size);
}

    In this way your operator new is called instead of the one in the standard library, and GDB will know where to jump.

    5

    inventore123:
    I’ve used C++ on an LPC2138, with JTAG and OpenOCD, and had no trouble stepping into objects constructed on the heap.

    What version of GCC are you using?

    gcc-4.3.2, glibc-2.7

    inventore123:
    Just a possible hack that could fix your debugging problem:

    you could overload the global operator new

    void *operator new(size_t size) throw()

    {
    return malloc(size);
    }

    


In this way your operator new is called instead of the one in the standard library, and GDB will know where to jump.

    I don’t think that it will be good choice. It lets to avoid the problem but doesn’t solve it. Thanks anyway :slight_smile: