I'm working on ARM system with gdb 7.1 (i've tried 7.5 too). I'm using this tool to debug an
application composed by several shared libraries.
If I debug this application on the ARM side, with gdb 7.1 i can see the
shared loaded libraries (digiting "share"). Perfect!
I'm trying to do the same thing remotelly with gdb for arm on windows
host and gdbserver on ARM.
So I have:
1) gdb on windows for arm v.7.4.1 (i've tried 7.3.1 too)
2) gdbserver on arm v.7.1 (i've tried 7.5 too)
On Windows I can debug everything flawless except for the shared
libraries: infact, when i tried to digit "share" it says there isn't any
shared loaded libraries. I'm absolutely sure that at least one library
has loaded (on arm side the same situation works fine).
Any idea?
Edit:
probably i've found something:
In gcc on arm, when i ask for shared loaded libraries ("share") it calls function solib.c:info_sharedlibrary_command with full support for solib. (and it works fine)
Instead, when i ask for the same command on gdb on windows and gdbserver on arm, it passes the command "qXfer:libraries:read:" that doesn't manage any solib, only dlls! And the dlls list is obviously empty.
Did i miss something?
Solved! http://sourceware.org/bugzilla/show_bug.cgi?id=14670
Related
Host system: x86-64 Linux, Ubuntu 20.04
Target system: aarch64 Linux, Debian 11, arm architecture: Cortex A53
I develop for an aarch64 based Linux system on matlab/simulink. This toolchain is currently worked out for Linux and Windows hosts. However due to additional IIO devices on the system it has become clear that the current approach of just hardcoding the IIO device numbers is not gonna work anymore.
Now I found libiio which works great when I compile simple programs on the target itself. However I have not managed to cross compile applications using the library.
I have been trying to cross compile the libiio library itself by making a cross compilation file:
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(CMAKE_STAGING_PREFIX /home/maud/development/stage)
set(tools /usr/aarch64-none-linux-gnu)
set(CMAKE_C_COMPILER ${tools}/bin/aarch64-none-linux-gnu-gcc)
set(CMAKE_CXX_COMPILER ${tools}/bin/aarch64-none-linux-gnu-g++)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
when I run cmake ../ -DCMAKE_TOOLCHAIN_FILE=~/development/crosscomp.cmake
from the build folder that I made in the libiio folder it seems to work fine. But when I run make the issue starts.
[ 28%] Building C object CMakeFiles/iio.dir/dns_sd_avahi.c.o
Reaping winning child 0x55c895073d40 PID 36856
Live child 0x55c895073d40 (CMakeFiles/iio.dir/dns_sd_avahi.c.o) PID 36858
/home/maud/Downloads/libiio-master/dns_sd_avahi.c:24:10: fatal error: avahi-common/address.h: No such file or directory
24 | #include <avahi-common/address.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~
I get this error, I do have libavahi-common-dev and libavahi-client-dev installed.
But I think it wants aarch64 compiled versions of the dependencies.
And it makes me question whether this is even a feasible goal, whether what I'm doing is even going to get me to where I want to be.
Is it even possible to add a library like this to such a cross compiling toolchain?
I tried taking the .so file from the target, but it will complain about missing a bunch of other dependencies. And even then I will only have managed to build from a Linux host, building from a Windows host feels like it would require way more trouble but I could be wrong. I'm still learning a lot about how all this works.
I got it mostly working, I compiled the library localy on my ARM system, but I tore out a bunch of features that I didnt need anyway. this left me with a library that didnt have any external dependencies (like the previously mentioned avahi common/client and a bunch more), then referencing it in my makefile and inluding the the header file got it working.
Was also able to cross compile from my x86 based host.
I've installed MinGW on my Linux machine and installed the MinGW package, however, I noticed that I can't run my program on Windows machines that don't have MinGW, I looked it up and soon found that the solution to this is to link statically. This worked, but it's still annoying to have to statically link everything and doesn't make much sense. I noticed that on my Windows machine where MinGW was installed I could compile a program without statically linking anything and the program would run successfully on any Windows machine regardless of whether it had MinGW installed or not.
My Linux box is running Arch Linux and Installed the mingw-w64-gcc AUR packages if that info helps at all.
Linux and Windows shared libraries / dynamically linked libraries are similar in how they get discovered. Your mingw program works in windows that has mingw installed because the installation likely added DLLs to your search path. Check out this article on DLL search order.
When you statically link, all that library code gets included in your executable.
If you want to share your mingw program with friends, then you need to also install all the shared libraries it uses in their search path. You can use sysinternals listdlls (or other tools) to find your dependencies, and include them in the same directory as your exe or install them to a library path (see the search order article).
You can also check out this article; How do I find out which dlls an executable will load? as it has lots of other options.
I try to debug some native code on Android with GBD. The code wasn't created by me and is not in an Android project, so I can't use the ndk-gdb tool. I use gdbserver on the android machine and connect to it from my mac with the normal GDB program. I try to load all the libraries (which should have symbols according to objdump tool), but gdb tells me that it does not load the symbols (according to the gdb command “info sharedLibrary”). These are the steps I took:
start gdbserver on Android machine
start GDB with the debug version of the binary
gdb symbols/system/bin/mediaserver
the following commands are executed in gdb itself
tell gdb where to look for the libraries with symbols
(gdb) set solib-search-path symbols/system/lib
tell gdb where to find the source files
(gdb) directory /sources
connect to remote target (Android machine)
(gdb) target remote 192.168.1.10:5039
GDB connects successfully to the running binary and I can pause and continue the execution. But it does not show me any debug information like function names or line numbers. It only shows adresses. When I check the status of the used libraries, I see that gdb thinks, they don’t have any symbols:
command in gdb:
(gdb) info sharedLibrary
From To Syms Read Shared Object Library
0x00003700 0x0000ff0c Yes /symbols/system/bin/linker
No libc.so
No libstdc++.so
No libm.so
No liblog.so
No libcutils.so
No libspeexresampler.so
No libaudioutils.so
No libgccdemangle.so
No libamplayer.so
Now for example the last library. When I check with the file command (not in gdb), it tells me that it is a not stripped library (the library is located in the "symbols/system/lib" folder).
file libamplayer.so
Output:
libamplayer.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped
objdump command shows a lot of symbols in it (I don’t show the output because it’s very long). So why does gdb not recognise the symbols in this libraries? I thought, at least line numbers and function names are present in not stripped versions of libraries. Or am I wrong? It would be very nice if someone could give me more insight.
Thanks!
System info:
GDB Version: 7.3.1-gg2 on Mac OS X Mavericks
The code wasn't created by me and is not in an Android project, so I can't use the ndk-gdb tool.
Your conclusion does not at all follow. ndk-gdb should be able to debug any Android program, whether created as a "project" or via other means.
I use gdbserver on the android machine and connect to it from my mac with the normal GDB program.
The normal GDB is likely not configured for cross-debugging, and thus doesn't understand ARM binaries at all. I am surprised you get as far using it as you do.
I am writing some code for raspberry pi ARM target on x86 ubuntu machine. I am using the gcc-linaro-armhf toolchain. I am able to cross compile and run some independent programs on pi. Now, I want to link my code with external library such as ncurses. How can I achieve this.
Should I just link my program with the existing ncurses lib on host machine and then run on ARM? (I don't think this will work)
Do I need to get source or prebuilt version of lib for arm, put it in my lib path and then compile?
What is the best practice in this kind of situation?
I also want to know how it works for the c stdlib. In my program I used the stdio functions and it worked after cross compiling without doing anything special. I just provided path for my arm gcc in makefile. So, I want to know, how it got correct std headers and libs?
Regarding your general questions:
Why the C library works:
The C library is part of your cross toolchain. That's why the headers are found and the program correctly links and runs. This is also true for some other very basic system libraries like libm and libstdc++ (not in every case, depends on the toolchain configuration).
In general when dealing with cross-development you need some way to get your desired libraries cross-compiled. Using binaries in this case is very rare. That is, especially with ARM hardware, because there are so many different configurations and often everything is stripped down much in different ways. That's why binaries are not very much binary compatible between different devices and Linux configurations.
If you're running Ubuntu on the Raspberry Pi then there is a chance that you may find a suitable ncurses library on the internet or even in some Ubuntu apt repository. The typical way, however, will be to cross compile the library with the specific toolchain you have got.
In cases when a lot and complex libraries need to be cross-compiled there are solutions that make life a bit easier like buildroot or ptxdist. These programs build complete Linux kernels and root file systems for embedded devices.
In your case, however, as long as you only want ncurses you can compile the source code yourself. You just need to download the sources, run configure while specifying your toolchain using the --host option. The --prefix option will choose the installation directory. After running make and make install, considering everything went fine, you will have got a set of headers and the ARM-compiled library for your application to link against.
Regarding cross compilation you will surely find loads of information on the internet and maybe ncurses has got some pointers in its shipped documentation, too.
For the query How the C library works in cross-tools
When compiling and building cross-tool chain during configuration they will provide sysroot.
like --with-sysroot=${CLFS_CROSS_TOOLS}
--with-sysroot
--with-sysroot=dir
Tells GCC to consider dir as the root of a tree that contains (a subset of) the root filesystem of the target operating system. Target system headers, libraries and run-time object files will be searched for in there. More specifically, this acts as if --sysroot=dir was added to the default options of the built compiler. The specified directory is not copied into the install tree, unlike the options --with-headers and --with-libs that this option obsoletes. The default value, in case --with-sysroot is not given an argument, is ${gcc_tooldir}/sys-root. If the specified directory is a subdirectory of ${exec_prefix}, then it will be found relative to the GCC binaries if the installation tree is moved.
So instead of looking /lib /usr/include it will look /Toolchain/(libc) and (include files) when its compiling
you can check by
arm-linux-gnueabihf-gcc -print-sysroot
this show where to look for libc .
also
arm-linux-gnueabihf-gcc -print-search-dirs
gives you clear picture
Clearly, you will need an ncurses compiled for the ARM that you are targeting - the one on the host will do you absolutely no good at all [unless your host has an ARM processor - but you said x86, so clearly not the case].
There MAY be some prebuilt libraries available, but I suspect it's more work to find one (that works and matches your specific conditions) than to build the library yourself from sources - it shouldn't be that hard, and I expect ncurses doesn't take that many minutes to build.
As to your first question, if you intend to use ncurses library with your cross-compiler toolchain, you'll have its arm-built binaries prepared.
Your second question is how it works with std libs, well it's really NOT the system libc/libm the toolchain is using to compile/link your program is. Maybe you'll see it from --print-file-name= option of your compiler:
arm-none-linux-gnuabi-gcc --print-file-name=libm.a
...(my working folder)/arm-2011.03(arm-toolchain folder)/bin/../arm-none-linux-gnuabi/libc/usr/lib/libm.a
arm-none-linux-gnuabi-gcc --print-file-name=libpthread.so
...(my working folder)/arm-2011.03(arm-toolchain folder)/bin/../arm-none-linux-gnuabi/libc/usr/lib/libpthread.so
I think your Raspberry toolchain might be the same. You can try this out.
Vinay's answer is pretty solid. Just a correction when compiling the ncurses library for raspberry pi the option to set your rootfs is --sysroot=<dir> and not --with-sysroot . Thats what I found when I was using the following compiler:
arm-linux-gnueabihf-gcc --version
arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) 4.8.3 20140303 (prerelease)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I am trying to create a development environment on my host machine that is identical (or as close to as possible) to the one on my embedded device using a chroot. Both host and target machines are x86 so I am not attempting to cross compile. I want to build GCC in my chroot and then using build libc and any other libs that are already on my embedded device (as well as any others that my executable will need to run in order to deploy on the device). In this way I am hoping to have all of the libs on my dev machine correctly linked with the appropriate version of libc.
My question is this - I know that the libc on the embedded device is 4.3.2 but how important is it that I use the same version of GCC to build the libraries locally on my dev machine?? Are there any potential complications if I actually use a more recent version (i.e. the one that came with my dev machine install which is 4.6.3) to build these libs??
As long as the ABI has not changed between compiler versions, you should be fine. From the back of my head, the C ABI hasn't changed in ages, and the C++ ABI not since 3.4 / 4.0. Check the official docs to be sure.