Wednesday, April 21, 2010
Optima debugger in softkernel halts before starting
Q: I am trying to get the debugger in the soft kernel for OSE5.4.1 going on Optima 2.x. I've followed the instructions in the Optima User Guide to the letter, and the soft kernel builds and runs, but when I try to debug it in Optima I get no further than this error:
Can't find a source file at "/cygdrive/c/OSE/ose5.4.1_ppc/src/osemain.c"
Locate the file or edit the source lookup path to include its location.
I thought I did everything right. Why is Optima complaining now?
Can't find a source file at "/cygdrive/c/OSE/ose5.4.1_ppc/src/osemain.c"
Locate the file or edit the source lookup path to include its location.
I thought I did everything right. Why is Optima complaining now?
A: The docs for Optima need a small amount of updating, mainly to account for the fact that they were written before the big split-off of the BSP products from the "mainline" OSE stream. Beginning in OSE5.3, BSPs were no longer delivered with the main OSE5 delivery and were purchased - and delivered - separately. Our BSP delivery docs advise users to install a directory heirarchy that co-locates the BSP at the save level with the OSE5 directory, rather than underneath it.
And now, the Optima tool runs in a completely different area of the product - within the BSP delivery, e.g. under C:/BSP_SFK_OSE5.4.1/refsys/rtose/sfk-win32. The config doc wasn't updated for this subtlety, which requires for Windows users adding a Path Mapping (under Eclipse C/C++ view in Debug -> Debug Configurations...). Hence the Optima tool's failure to find the source paths for osemain.c, which is located under the OSE5 mainline directory under C:/OSE/OSE5.4.1_PPC/src .
The simplest solution is to follow the button titled "Locate File..." as shown above in the pic. Using the standard windows file dialogue, just add the full path to the osemain.c in OSE5.4.1_PPC mainline area. You'll also have to add this for hello.c if you continue following the doc example (when it tells you to step over the hello.c breakpoint). This will automagically add the desired Path Mapping entries in your Debug Configuration for this debug run, where it can be found later under the Source tab.
Labels: debugger, gdb, Optima, OSE5, OSE5.3, OSE5.4
Tuesday, April 13, 2010
Strange link errors when building load modules
Q: One of our customers is trying to build pbench as a load module with BSP_MPC8377_OSE5.4 and getting link errors. We can build the same lm on the same release and bsp without errors. What is going on?
$ make lm
/home/user1/OSE/BSP_MPC8377_OSE5.4/refsys/modules/pbench
--- Preprocessing linker control file obj/powerpc/debug/gcc_lm.lcf ../../compilers/gcc_lm.lcf
--- Linking obj/powerpc/debug/unconfigured (pass 1)
--- Linking obj/powerpc/debug/unconfigured (pass 2)
obj/powerpc/debug/unconfigured_ro: In function `clib_pointer':
stdout.c:(.text+0xac54): undefined reference to `_SDA2_BASE_'
obj/powerpc/debug/unconfigured_ro: In function `zzinit_OSE': (.text+0xacae): undefined reference to `_SDA_BASE_'
obj/powerpc/debug/unconfigured_ro: In function `zzinit_OSE':
(.text+0xacb2): undefined reference to `_SDA_BASE_'
make: *** [obj/powerpc/debug/unconfigured] Error 1
A: These bizarre errors, which leave no clue as to their true cause, can occur if the user doesn't use the toolchain version that is shipped for the corresponding OSE version. In other words, newer or older compilers may present unforseen problems. In this case, toolchain is GNU, and the _SDA_BASE_ and similiar vars are already part of our CRT library but weren't being pulled in due to a later GNU ld version of 2.19 instead of the 2.16.1 version we ship for OSE5.4.1. A quick version check is always useful:
$ which powerpc-eabi-ld
/cygdrive/c/OSE/OSE5.4.1_PPC/gcc_win32_powerpc_4.2.3/bin/powerpc-eabi-ld
$ powerpc-eabi-ld -v
GNU ld version 2.16.1
$ make lm
/home/user1/OSE/BSP_MPC8377_OSE5.4/refsys/modules/pbench
--- Preprocessing linker control file obj/powerpc/debug/gcc_lm.lcf ../../compilers/gcc_lm.lcf
--- Linking obj/powerpc/debug/unconfigured (pass 1)
--- Linking obj/powerpc/debug/unconfigured (pass 2)
obj/powerpc/debug/unconfigured_ro: In function `clib_pointer':
stdout.c:(.text+0xac54): undefined reference to `_SDA2_BASE_'
obj/powerpc/debug/unconfigured_ro: In function `zzinit_OSE': (.text+0xacae): undefined reference to `_SDA_BASE_'
obj/powerpc/debug/unconfigured_ro: In function `zzinit_OSE':
(.text+0xacb2): undefined reference to `_SDA_BASE_'
make: *** [obj/powerpc/debug/unconfigured] Error 1
A: These bizarre errors, which leave no clue as to their true cause, can occur if the user doesn't use the toolchain version that is shipped for the corresponding OSE version. In other words, newer or older compilers may present unforseen problems. In this case, toolchain is GNU, and the _SDA_BASE_ and similiar vars are already part of our CRT library but weren't being pulled in due to a later GNU ld version of 2.19 instead of the 2.16.1 version we ship for OSE5.4.1. A quick version check is always useful:
$ which powerpc-eabi-ld
/cygdrive/c/OSE/OSE5.4.1_PPC/gcc_win32_powerpc_4.2.3/bin/powerpc-eabi-ld
$ powerpc-eabi-ld -v
GNU ld version 2.16.1
Labels: gcc, linker, lm, OSE5.4, OSE5.4.1
free invisible web counter
