I have installed Eclipse CDT, CodeSourcery G++ toolchain on Linux host. I am using the Code Sourcery Eclipse IDE. I have installed Linux kernel using Linux Target Image Builder from the Freescale site, onto the MCF5485 board.
I have created a "helloworld" project on my Linux host using the Sourcery Eclipse IDE.
I have copied the executables(like gdbserver,catchsgev etc) from the Sourcery folder onto the board in the root filesystem.
I run the gdbserver on the board and then debug using TCP from my Linux machine.
In the Sourcery Eclipse IDE I have specified sysroot on target as / because I have installed gdbserver in the root on the board (/root/bin).
I have specified the IP address in the debug configuration in Eclipse while rest is default.
I have selected the option "Translate sysroot pathnames" in the Shared Libraries tab in Debug Configurations
I start gdbsrver on board (gdbserver IP:port /pathname/to/executable) and then I launch debug configuration on Linux host. It stops at main() because of breakpoint. When I press resume it gives me the following error.
warning: .dynamic section for "C:\\Program Files\\CodeSourcery\\Sourcery G++\\m68k-linux-gnu\\libc/lib/libc.so.6" is not at the expected address (wrong library or version mismatch?)
Stopped due to shared library event
Stopped due to shared library event
Stopped due to shared library event
My program is as follows:
include <stdio.h>
int main(void)
{
int i=0;
printf("Hello = %d",i);
return 0;
}
I read on some forum that I need to set sysroot but I also read that if I have installed sysroot in the root filesystem on the board I do not need to do anything.
Not sure you need to put the Code Sourcery tools on the target, but it does look like the GDB client or Eclipse can not find the target libraries, or the target library does not match the library the Code Sourcery tools are using.
I would expect these libraries to be built as a part of the target linux build. They need to be cross compiled for your target processor, and would end up on your target file system under /lib directory. Code Sourcery might provide pre-built lib's for your target, and then these must be the libraries your target should be using. they need to be part of your target's file system.
Related
I have source code pack which includes eCos source, GSS-3.2.1 compiler and and GCC-toolchain. I want to compile source code for MIPS32 target CPU. The host PC is Ubuntu Linux x86/64. The 'Readme' file have short instructions for building GCC 3.2.1 and eCos library.
As was specified there, in order to compile eCos, I will need to download GCC version 3.2.1 (GCC 3.2.1). In addition, there are note: "The build instructions given here are for the default GCC target platform CPU(i686-linux). This means that the library files created here can not be loaded onto a BRCM MIPS CPU."
Whereas, I want to create files specifically for Broadcom MIPS32 CPU. (BCM33xx)
So, its not clear, how to compile source code for embedded MIPS32 CPU on Linux x86/64 host PC?
Edit: Source package includes also gcc cross-compiler toolchain (gcc-toolchain.tar), containing folder tree:
/usr/local/ecos20/gnutools/mipsisa32-elf-i386-linux/
Then it's not clear does anything else is needed to compile code and all library files for MIPS32?
I am trying to update our cross compiler toolchain from crosstool to crosstool-ng. We are using an old kernel and build machine. I could install and configure crosstool-ng-1.0.0 on the server and build the toolchain.
One difference that I have noticed between the output of crosstool and crosstool-ng is that the crosstool-ng is missing some of library under output folder. For example libcrypt.a, libdl.a, libnss_dns.so, libpthread.so and so on.
I have noticed that while building with crosstool we are setting KERNELCONFIG to a specific kernel configuration file. In that configuration file we have configurations like:
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=ycryp
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_DES=y
Is this the reason that libraries like libcrypt are missing. In that case is there a way to set KERNELCONFIG in crosstool-ng for example as a build parameter?
All the libraries you mention are part of glibc, and the glibc build does not depend on the kernel configuration at all. You should check if you have enabled building glibc at all.
I am using Buildroot 2018.02 for an IMX6 board and the Linaro external toochain 2017.11 based on GCC 2017.11 (GCC 7.2.1)
Now i am adding some debug tools such as gdbserver on the target.
Everything is OK if i use the option "Build cross gdb for the host" and selecting the gdb debugger version 7.11.x for the host along with the gdbserver (BR2_PACKAGE_GDB_SERVER) in the "Target Packages > Debugging,.." menu. There are also other version of gdb available in Buildroot such as 7.12.x and 8.0.x.
However, for an external toolchain the recommended way is :
https://github.com/mbats/eclipse-buildroot-bundle/wiki/Tutorial-:-How-to-debug-a-remote-application-%3F which means to activate only the "Copy gdb server to the Target" option in Buildroot (although the post is a bit old)
I have noticed that the BR2_TOOLCHAIN_EXTERNAL_LINARO_ARM description says that Linaro gdb is based on gdb 8.0 so a newer version that the one i am using (7.11.x).
But when i do that, i have the following message on the target board :
# gdbserver
-sh: gdbserver: not found
despite the following :
# which gdbserver
/usr/bin/gdbserver
gdbserver binary is on the target.
How to fix this in Buildroot ?
Moreover i have two additional questions :
Does it really matter to have the Linaro toolchain gdb instead of
the gdb 7.11.x that works "out of the box" in my case ?
If i don't use the Linaro gdb then should i use the gdb version
8.0.x ( because the Linaro version is based on the 8.0 of GDB ) ?
Thank you for your help.
The gdbserver binary in the Linaro 2017.11 toolchain is broken: it requests /usr/lib/ld.so.1 as the program interpreter (see below), but that program interpreter doesn't exist.
You can try to create a symlink /usr/lib/ld.so.1 -> /lib/ld-linux-armhf.so.3 (add that to your filesystem overlay if it works). Alternatively, you can specify the program interpreter explicitly by putting it before the executable, i.e. /lib/ld-linux-armhf.so.3 /usr/bin/gdbserver.
The "program interpreter" is a parameter of an ELF file that points to a program that is used to load the ELF file into memory and to start executing it. The main responsibility of the program interpreter is to find and load the dynamic libraries that the program needs. Thus, it is usually called the "dynamic library loader", or ld.so. It is built and installed together with the toolchain - specifically, the standard C library (glibc). When a program is linked, the linker will also set the program interpreter (it is copied from libc.so). Apparently Linaro did something really peculiar to end up with a wrong program interpreter in the gdbserver executable.
# gdbserver
-sh: gdbserver: not found
depsite the following :
# which gdbserver
/usr/bin/gdbserver
Most likely:
The gdbserver is a dynamically linked binary, and
The ELF interpreter that this binary is linked to use is not present on the target system.
Use readelf -l /usr/bin/gdbserver | grep -i interpreter to find out what runtime loader this gdbserver requires. Verify that that file is not present on the target. Copy it to the target and enjoy.
I am trying to insert a .ko kernel module into the linux running in arm processor. I built a .ko file in my desk PC which is a x86 one. How do I cross compile it to arm specs. I am new to this field.
Thanks in advance
For that you need to download the ARM compilers first. I suggest you download the compiler from http://www.linaro.org/downloads/ then set the CROSS_COMPILE environment variable to arm-linux-gcc.
set the bin directory path in PATH variable.You can do it by export PATH=$PATH:/path/to/arm/binaries/
Finally compile the code then run in ARM.
use file <filename> whether it is ARM executable or not.
For this you have to do the following steps.
Check you have cross compiler tool chain or not.
If you don't have cross compiler tool chain
you can download from one of the free ARM cross compiler from net.
You can generate your own cross tool chain using Buildroot tool. below you can get the link of Buildroot user manual.
http://buildroot.uclibc.org/downloads/manual/manual.html#_using_buildroot
Install cross tool chain in your host PC.
Export the cross tool chain path in your host PC using export command.
Change the make file of the kernel module to set the compiler as CROSS_COMPILE.
Do make.
Move the .ko file to target and insert it.
I have a following setup. Although my working setup deals with ARM compiler Real View Developer Suite (RVDS) 3.2 on a Windows host, the situation could be generic for any other C compiler on any host.
I build a ARM library (static library - .a file) of C code using RVDS 3.2 compiler toolchain on Windows host. Then I link this library with an application using an ARM-Linux compiler toolchain on a Linux host, to get a ARM executable. Now when I try to debug this generated ARM executable on Linux using gdb, by trying to put a breakpoint in some function which is present in the library that is linked, gdb is not able to put breakpoint there citing source not found. So I manually copied all the source files(*.c) used to create the library in the Linux folder where the executable file is present. Still gdb fails to put a breakpoint.
So now I started thinking:
How can I do source level debugging of this library which I create on Windows using a different compiler chain by launching the executable which is generated by linking this library to an application, in gdb. Is it possible? How can I do it? Is there any compiler option in RVDS compiler toolchain to enable this library source level debug?
Do I need to copy the source files to linux in exactly same folder structure as that is present in windows for those source files?
You could try to see if mimicking the exact same directory structure works. If you're not sure what directory structure the compiler annotated in the debug info in the executable, you can always look at it with dwarfdump (on linux).
First, GDB does not need any source to put breakpoints on functions; so your description of what is actually happening is probably inaccurate. I would start by verifying that the function you want to break on is actually there in the binary:
nm /path/to/app | grep function_desired
Second, to do source level debugging, GDB needs debug info in a format GDB understands. On Linux this generally means DWARF or STABS. It is quite possible that your RVDS compiler does not emit such debug info; if so, source level debugging will not be possible.
Did you build the library with debugging enabled (-g option)? Without that, there would be difficulties identifying lines etc.
I've found that -fPIC will cause this sort of issue, but the only work around I've found is to not use -fPIC when I want to debug.