Dear stackoverflow community.
I'm cross-compiling Qt 5.12 for my Beaglebone Black with EGL support. The host OS is Ubuntu 18.04.1 LTS (x64) running in a VM. I have installed any possible dependcies (I could find in different posts) on the target (and some on the host as well) and copied a sysroot over to the host. Basically I followed this guide which is originally for RPi2: https://wiki.qt.io/RaspberryPi2EGLFS
The Qt5base package compiles fine, at least I do think so. It makes and installs, but there are some errors from configuration tests. I will come back to them later.
Now I try to build qtdeclarative as well. Qmake runs without any error, but the make fails with a linkage error. libQt5Core.so cannot find some references because some dependencies are not found. For example libicudata.so.57. Of course I checked they are in the right place under sysroot and they are.
I suppose there is something wrong with the original qtbase build, because I had similar errors from some configuration tests (but with different libraries) and if I try to build an example application it is the same.
Here are some information...
The configuration command line from the qtbase build:
Command line: -release -opengl es2 -device linux-beagleboard-g++ -device-option CROSS_COMPILE=/home/martin/beaglebone/tools/gcc-linaro-6.4.1-2018.05-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf- -sysroot /home/martin/beaglebone/sysroot -opensource -confirm-license -make libs -make tools -prefix /usr/local/qt5bbb -extprefix /home/martin/beaglebone/qt5build/qt5bbb -hostprefix /home/martin/beaglebone/qt5build/qt5 -qt-zlib -qt-libpng -no-use-gold-linker -v
The dump of all qmake persistent variables:
~/beaglebone/qt5build/qt5/bin/qmake -query
QT_SYSROOT:/home/martin/beaglebone/sysroot
QT_INSTALL_PREFIX:/home/martin/beaglebone/qt5build/qt5bbb
QT_INSTALL_PREFIX/dev:/usr/local/qt5bbb
QT_INSTALL_ARCHDATA:/home/martin/beaglebone/qt5build/qt5bbb
QT_INSTALL_ARCHDATA/dev:/usr/local/qt5bbb
QT_INSTALL_DATA:/home/martin/beaglebone/qt5build/qt5bbb
QT_INSTALL_DATA/dev:/usr/local/qt5bbb
QT_INSTALL_DOCS:/home/martin/beaglebone/qt5build/qt5bbb/doc
QT_INSTALL_DOCS/dev:/usr/local/qt5bbb/doc
QT_INSTALL_HEADERS:/home/martin/beaglebone/qt5build/qt5bbb/include
QT_INSTALL_HEADERS/dev:/usr/local/qt5bbb/include
QT_INSTALL_LIBS:/home/martin/beaglebone/qt5build/qt5bbb/lib
QT_INSTALL_LIBS/dev:/usr/local/qt5bbb/lib
QT_INSTALL_LIBEXECS:/home/martin/beaglebone/qt5build/qt5bbb/libexec
QT_INSTALL_LIBEXECS/dev:/usr/local/qt5bbb/libexec
QT_INSTALL_BINS:/home/martin/beaglebone/qt5build/qt5bbb/bin
QT_INSTALL_BINS/dev:/usr/local/qt5bbb/bin
QT_INSTALL_TESTS:/home/martin/beaglebone/qt5build/qt5bbb/tests
QT_INSTALL_TESTS/dev:/usr/local/qt5bbb/tests
QT_INSTALL_PLUGINS:/home/martin/beaglebone/qt5build/qt5bbb/plugins
QT_INSTALL_PLUGINS/dev:/usr/local/qt5bbb/plugins
QT_INSTALL_IMPORTS:/home/martin/beaglebone/qt5build/qt5bbb/imports
QT_INSTALL_IMPORTS/dev:/usr/local/qt5bbb/imports
QT_INSTALL_QML:/home/martin/beaglebone/qt5build/qt5bbb/qml
QT_INSTALL_QML/dev:/usr/local/qt5bbb/qml
QT_INSTALL_TRANSLATIONS:/home/martin/beaglebone/qt5build/qt5bbb/translations
QT_INSTALL_TRANSLATIONS/dev:/usr/local/qt5bbb/translations
QT_INSTALL_CONFIGURATION:/home/martin/beaglebone/qt5build/qt5bbb/etc/xdg
QT_INSTALL_CONFIGURATION/dev:/usr/local/qt5bbb/etc/xdg
QT_INSTALL_EXAMPLES:/home/martin/beaglebone/qt5build/qt5bbb/examples
QT_INSTALL_EXAMPLES/dev:/usr/local/qt5bbb/examples
QT_INSTALL_DEMOS:/home/martin/beaglebone/qt5build/qt5bbb/examples
QT_INSTALL_DEMOS/dev:/usr/local/qt5bbb/examples
QT_HOST_PREFIX:/home/martin/beaglebone/qt5build/qt5
QT_HOST_DATA:/home/martin/beaglebone/qt5build/qt5
QT_HOST_BINS:/home/martin/beaglebone/qt5build/qt5/bin
QT_HOST_LIBS:/home/martin/beaglebone/qt5build/qt5/lib
QMAKE_SPEC:linux-g++
QMAKE_XSPEC:devices/linux-beagleboard-g++
QMAKE_VERSION:3.1
QT_VERSION:5.12.2
A snippet from the failing qtdeclarative build:
/home/martin/beaglebone/tools/gcc-linaro-6.4.1-2018.05-x86_64_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/6.4.1/../../../../arm-linux-gnueabihf/bin/ld: warning: libicudata.so.57, needed by /home/martin/beaglebone/qt5build/qt5bbb/lib/libQt5Core.so, not found (try using -rpath or -rpath-link)
/home/martin/beaglebone/qt5build/qt5bbb/lib/libQt5Core.so: Warnung: undefinierter Verweis auf »ucol_getSortKey_57«
The header of the mentioned so:
readelf -d /home/martin/beaglebone/qt5build/qt5bbb/lib/libQt5Core.so
Dynamic section at offset 0x4125b0 contains 37 entries:
Tag Typ Name/Wert
0x00000001 (NEEDED) Gemeinsame Bibliothek [libpthread.so.0]
0x00000001 (NEEDED) Gemeinsame Bibliothek [libicui18n.so.57]
0x00000001 (NEEDED) Gemeinsame Bibliothek [libicuuc.so.57]
0x00000001 (NEEDED) Gemeinsame Bibliothek [libicudata.so.57]
0x00000001 (NEEDED) Gemeinsame Bibliothek [librt.so.1]
0x00000001 (NEEDED) Gemeinsame Bibliothek [libdl.so.2]
0x00000001 (NEEDED) Gemeinsame Bibliothek [libstdc++.so.6]
0x00000001 (NEEDED) Gemeinsame Bibliothek [libm.so.6]
0x00000001 (NEEDED) Gemeinsame Bibliothek [libgcc_s.so.1]
0x00000001 (NEEDED) Gemeinsame Bibliothek [libc.so.6]
0x00000001 (NEEDED) Gemeinsame Bibliothek [ld-linux-armhf.so.3]
0x0000000e (SONAME) soname der Bibliothek: [libQt5Core.so.5]
0x0000000c (INIT) 0x6ab1c
0x0000000d (FINI) 0x298ed0
0x00000019 (INIT_ARRAY) 0x41c000
0x0000001b (INIT_ARRAYSZ) 16 (Bytes)
0x0000001a (FINI_ARRAY) 0x41c010
0x0000001c (FINI_ARRAYSZ) 12 (Bytes)
0x00000004 (HASH) 0x158
0x00000005 (STRTAB) 0x20c6c
0x00000006 (SYMTAB) 0x838c
0x0000000a (STRSZ) 228634 (Bytes)
0x0000000b (SYMENT) 16 (Bytes)
0x00000003 (PLTGOT) 0x4226f8
0x00000002 (PLTRELSZ) 24664 (Bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x64ac4
0x00000011 (REL) 0x5beac
0x00000012 (RELSZ) 35864 (Bytes)
0x00000013 (RELENT) 8 (Bytes)
0x6ffffffc (VERDEF) 0x5baa4
0x6ffffffd (VERDEFNUM) 16
0x6ffffffe (VERNEED) 0x5bccc
0x6fffffff (VERNEEDNUM) 8
0x6ffffff0 (VERSYM) 0x58986
0x6ffffffa (RELCOUNT) 1928
0x00000000 (NULL) 0x0
A locate search for libicudata:
locate libicudata.so.57
/home/martin/beaglebone/sysroot/lib/arm-linux-gnueabihf/libicudata.so.57
/home/martin/beaglebone/sysroot/usr/lib/arm-linux-gnueabihf/libicudata.so.57
/home/martin/beaglebone/sysroot/usr/lib/arm-linux-gnueabihf/libicudata.so.57.1
/home/martin/raspi/sysroot/usr/lib/arm-linux-gnueabihf/libicudata.so.57
/home/martin/raspi/sysroot/usr/lib/arm-linux-gnueabihf/libicudata.so.57.1
How does the linker search for dependencies of dynamic libraries? Could it be the "double match" because I have a RPi3 sysroot on the same host as well?
I can provide configuration log from the qtbase build, if that is helpful.
Thanks and best regards,
Martin.
I went to the same pain over and over. Use the chroot and compile there. Here is my whole post
Related
I'm using Eclipse based CubeIDE and QEMU debugging plugin.
I'm working in assembler and can debug simple project (adding two numbers in registers) on STM32 Cortex M7 board (STM32H750DK). Now I'd like to do the same using QEMU and have problems, because I can't find suitable generic Cortex M7 machine. I've tried mps2-an500, but it doesn't work.
I've done similar already under qemu-system-gnuarmeclipse.exe on STM32F407 board and it's supported even visually (board picture), and I can see LED diodes blinking.
I'd be enough just plain emulation (not visual) for cortex M7 board.
Has anyone done something similar or any other advice how to do this properly ?
Thanks.
I think you are supposed to show some code for the attempts you made when asking a question on Stackoverflow.
In your case, this could have been a minimal, reproducible example of your attempts to use the mps2-an500 QEMU virtual machine.
This being said, a procedure for building and debugging a program using QEMU and targeting the mps2-an500 virtual machine could be:
Download QEMU 7.10 for Windows, and install it into the \opt\qemu-7.1.0 directory - you will have to create it,
Download the arm-gnu-toolchain-11.3.rel1-mingw-w64-i686-arm-none-eabi toolchain,and install into the \opt\arm\11 directory - you will have to create it,
In a directory of your choice, create the following files:
build.cmd:
#set CROSS_COMPILE=\opt\arm\11\arm-gnu-toolchain-11.3.rel1-mingw-w64-i686-arm-none-eabi\bin\arm-none-eabi-
#set CC=%CROSS_COMPILE%gcc
#set OBJDUMP=%CROSS_COMPILE%objdump
#set GDB=%CROSS_COMPILE%gdb
#set QEMU_SYSTEM_ARM=\opt\qemu-7.1.0\qemu-system-arm
#%CC% -g -mthumb -mtune=cortex-m7 -nostdlib -nostartfiles -ffreestanding -Wl,-Ttext,0x00000000 -o mps2-an500.elf startup.s
#%OBJDUMP% -d mps2-an500.elf > mps2-an500.objdump
#echo QEMU/GDB commands:
#echo %QEMU_SYSTEM_ARM% -m 16M -nographic -machine mps2-an500 -S -cpu cortex-m7 -gdb tcp::2345,ipv4 -kernel mps2-an500.elf
#echo %GDB%
startup.s:
.file "startup.s"
.arch armv7-a
.fpu vfpv3-d16
.thumb
.syntax unified
.equ __StackTop, 0x21000000
.global _start
.align 2
.long __StackTop
.long _start
_start:
mov r0,#3
mov r1,#5
add r2, r0, r1
wait: b wait
.size _start, .-_start
.end
Execute the build.cmd batch procedure, it will create mps2-an500.elf and mps2-an500.lst, and display the QEMU and GDB commands you will use for debugging the (very) basic example:
build.cmd
QEMU/GDB commands:
\opt\qemu-7.1.0\qemu-system-arm -m 16M -nographic -machine mps2-an500 -S -cpu cortex-m7 -gdb tcp::2345,ipv4 -kernel mps2-an500.elf
\opt\arm\11\arm-gnu-toolchain-11.3.rel1-mingw-w64-i686-arm-none-eabi\bin\arm-none-eabi-gdb
In one console mode session, execute:
\opt\qemu-7.1.0\qemu-system-arm -m 16M -nographic -machine mps2-an500 -S -cpu cortex-m7 -gdb tcp::2345,ipv4 -kernel mps2-an500.elf
in another, execute the GDB command:
\opt\arm\11\arm-gnu-toolchain-11.3.rel1-mingw-w64-i686-arm-none-eabi\bin\arm-none-eabi-gdb --command=mps2-an500.gdb
In the GDB session, execute the following commands in sequence:
target remote localhost:2345
file mps2-an500.elf
break _start
break wait
set $sp = 0x21000000
set $pc = _start
stepi
stepi
stepi
info registers
The transcript for the GDB session should look like:
\opt\arm\11\arm-gnu-toolchain-11.3.rel1-mingw-w64-i686-arm-none-eabi\bin\arm-none-eabi-gdb
GNU gdb (Arm GNU Toolchain 11.3.Rel1) 12.1.90.20220802-git
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.linaro.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) target remote localhost:2345
Remote debugging using localhost:2345
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x00000014 in ?? ()
(gdb) file mps2-an500.elf
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading symbols from mps2-an500.elf...
(gdb) break _start
Breakpoint 1 at 0x8: file startup.s, line 12.
(gdb) break wait
Breakpoint 2 at 0x14: file startup.s, line 15.
(gdb) set $sp = 0x21000000
(gdb) set $pc = _start
(gdb) stepi
13 mov r1,#5
(gdb) stepi
14 add r2, r0, r1
(gdb) stepi
Breakpoint 2, _start () at startup.s:15
15 wait: b wait
(gdb) info registers
r0 0x3 3
r1 0x5 5
r2 0x8 8
r3 0x0 0
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x0 0
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x21000000 0x21000000
lr 0xfffffff9 -7
pc 0x14 0x14 <_start+12>
xpsr 0x41000003 1090519043
fpscr 0x0 0
(gdb)
I have compiled and ran a simple hello world program on ARM Foundation Platform. The code is given below.
#include <stdio.h>
int main(int argc, char *argv[])
{
printf("Hello world!\n");
return 0;
}
This program is compiled and linked using ARM GNU tool chain as given below.
$aarch64-none-elf-gcc -c -march=armv8-a -g hello.c hello.o
aarch64-none-elf-gcc: warning: hello.o: linker input file unused because linking not done
$aarch64-none-elf-gcc -specs=aem-ve.specs -Wl,-Map=linkmap.txt hello.o -o hello.axf
I could successfully execute this program on ARM Foundation Platform (I think, foundation platform is similar to ARM Fixed Virtual Platform) and it prints "Hello world!"
The contents of 'aem-ve.specs' file is given below:
cat ./aarch64-none-elf/lib/aem-ve.specs
# aem-ve.specs
#
# Spec file for AArch64 baremetal newlib, libgloss on VE platform with version 2
# of AngelAPI semi-hosting.
#
# This Spec file is also appropriate for the foundation model.
%rename link old_link
*link:
-Ttext-segment 0x80000000 %(old_link)
%rename lib libc
*libgloss:
-lrdimon
*lib:
cpu-init/rdimon-aem-el3.o%s --start-group %(libc) %(libgloss) --end-group
*startfile:
crti%O%s crtbegin%O%s %{!pg:rdimon-crt0%O%s} %{pg:rdimon-crt0%O%s}
Is it possible to execute the same binary on QEMU? If so could you please share the sample command. If not, could you please share the right and best way to execute it on QEMU?
I have traced instruction execution of Foundation platform using the "trace" option and analysed using 'tarmac-profile' tool and 'Tarmac-calltree' tool. The outputs are given below:
$ ./tarmac-profile hello.trace --image hello.axf
Address Count Time Function name
0x80000000 1 120001
0x80001030 1 30001 register_fini
0x80001050 1 60001 deregister_tm_clones
0x800010c0 1 210001 __do_global_dtors_aux
0x80001148 1 23500001 frame_dummy
0x800012c0 1 10480001 main
0x80002000 1 40001 main
0x80003784 1 360001 main
0x80003818 1 460001 _cpu_init_hook
0x80003870 1 590001 _write_r
0x800038d0 1 1090001 __call_exitprocs
...
...
./tarmac-calltree hello.trace --image hello.axf
o t:10000 l:2288 pc:0x80001148 - t:23510000 l:7819 pc:0x80008060 : frame_dummy
- t:240000 l:2338 pc:0x800011a8 - t:720000 l:2443 pc:0x800011ac
o t:250000 l:2340 pc:0x80003818 - t:710000 l:2442 pc:0x80003828 : _cpu_init_hook
- t:260000 l:2343 pc:0x8000381c - t:320000 l:2354 pc:0x80003820
o t:270000 l:2345 pc:0x80002000 - t:310000 l:2353 pc:0x80002010 : main
- t:320000 l:2354 pc:0x80003820 - t:700000 l:2436 pc:0x80003824
o t:330000 l:2356 pc:0x80003784 - t:690000 l:2435 pc:0x80003814 : main
- t:760000 l:2453 pc:0x800011bc - t:2010000 l:2970 pc:0x800011c0
o t:770000 l:2455 pc:0x80004200 - t:2000000 l:2969 pc:0x800042c0 : memset
- t:2010000 l:2970 pc:0x800011c0 - t:4870000 l:3587 pc:0x800011c4
o t:2020000 l:2972 pc:0x80007970 - t:4860000 l:3586 pc:0x80007b04 : initialise_monitor_handles
- t:2960000 l:3165 pc:0x80007b24 - t:4340000 l:3465 pc:0x80007b28
I have tried the following method to execute on QEMU, without any success.
I have started the QEMU with gdb based debugging through TCP Port
$ qemu-system-aarch64 -semihosting -m 128M -nographic -monitor none -serial stdio -machine virt,gic-version=2,secure=on,virtualization=on -cpu cortex-a53 -kernel hello.axf -S -gdb tcp::9000
The result of debug session is given below:
gdb) target remote localhost:9000
Remote debugging using localhost:9000
_start () at /data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/libgloss/aarch64/crt0.S:90
90 /data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/libgloss/aarch64/crt0.S: No such file or directory.
(gdb) si
<The system hangs here>
I have tried to disassemble the code using gdb and its output is given below. It looks like the code is not loaded correctly
(gdb) disas frame_dummy
Dump of assembler code for function frame_dummy:
0x0000000080001110 <+0>: udf #0
0x0000000080001114 <+4>: udf #0
0x0000000080001118 <+8>: udf #0
0x000000008000111c <+12>: udf #0
0x0000000080001120 <+16>: udf #0
0x0000000080001124 <+20>: udf #0
0x0000000080001128 <+24>: udf #0
0x000000008000112c <+28>: udf #0
0x0000000080001130 <+32>: udf #0
0x0000000080001134 <+36>: udf #0
0x0000000080001138 <+40>: udf #0
0x000000008000113c <+44>: udf #0
0x0000000080001140 <+48>: udf #0
0x0000000080001144 <+52>: udf #0
End of assembler dump.
Could you please shed some light on this. Any hint given is appreciated very much.
The Foundation Model and the QEMU 'virt' board are not the same machine type. They have different devices at different physical addresses, and in particular they do not have RAM at the same address. To run bare metal code on the 'virt' machine type you will need to adjust your code. This is normal for bare metal -- the whole point is that you are running directly on some piece of (emulated) hardware and need to match the details of it.
Specifically, the minimum change you need to make here is that the RAM on the 'virt' board starts at 0x4000_0000, not the 0x8000_0000 that the Foundation Model uses. There may be others as well, but that is the immediate cause of what you're seeing.
I am having trouble completely compiling lighttpd statically. I have followed the directions in the INSTALL file using autotools:
LIGHTTPD_STATIC=yes ./configure -C --enable-static=yes
I have also added "-static" to CFLAGS during compilation as well. However, when I check the elf file to see if it is completely static, I get the following output (using readelf):
Dynamic section at offset 0x98e10 contains 25 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libcrypt.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000000000000c (INIT) 0x408000
0x000000000000000d (FINI) 0x479eb0
0x0000000000000019 (INIT_ARRAY) 0x499e00
0x000000000000001b (INIT_ARRAYSZ) 8 (bytes)
0x000000000000001a (FINI_ARRAY) 0x499e08
0x000000000000001c (FINI_ARRAYSZ) 8 (bytes)
0x000000006ffffef5 (GNU_HASH) 0x400308
0x0000000000000005 (STRTAB) 0x404288
0x0000000000000006 (SYMTAB) 0x400f40
0x000000000000000a (STRSZ) 9392 (bytes)
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000015 (DEBUG) 0x0
0x0000000000000003 (PLTGOT) 0x49a000
0x0000000000000002 (PLTRELSZ) 3840 (bytes)
0x0000000000000014 (PLTREL) RELA
0x0000000000000017 (JMPREL) 0x406cf8
0x0000000000000007 (RELA) 0x406c50
0x0000000000000008 (RELASZ) 168 (bytes)
0x0000000000000009 (RELAENT) 24 (bytes)
0x000000006ffffffe (VERNEED) 0x406b80
0x000000006fffffff (VERNEEDNUM) 2
0x000000006ffffff0 (VERSYM) 0x406738
0x0000000000000000 (NULL) 0x0
Specifically, I would like to statically compile libc into my lighttpd binary rather than including it dynamically. Any input would be greatly appreciated on how to accomplish this.
Different systems and different libc might not work well with static builds of 100% of the libraries. It does not matter specifically to the lighttpd base, but it may matter to the dependencies of some lighttpd modules on other third-party libraries.
It is probably possible to adjust your environment so that autoconf prefers the all static libraries. However, before doing that, I suggest trying to use SCons to build lighttpd statically:
https://wiki.lighttpd.net/InstallFromSource
Review the contents of sconsbuild/build/plugin-static.h and remove what you do not need.
Are there any tools or libraries one can use on Linux to get the original (source) instruction only from the PID and the current instruction pointer address, even if the IP currently points into a shared library?
AFAIK it should be possible, since the location of the library mapping is available through /proc/[PID]/maps, though I haven't found any applications or examples doing so.
Any suggestions?
EDIT: an assembly instruction or the nearest symbol suffice (source code line is not necessarily needed)
I found a way to do this with GDB:
Interactive:
$ gdb --pid 1566
(gdb) info symbol 0x7fe28b8a2b79
pselect + 89 in section .text of /lib/x86_64-linux-gnu/libc.so.6
(gdb) info symbol 0x5612550f14a4
copy_word_list + 20 in section .text of /usr/bin/bash
(gdb) info symbol 0x7fe28b878947
execve + 7 in section .text of /lib/x86_64-linux-gnu/libc.so.6
Shows exactly what I wanted!
It can also be scripted:
gdb -q --pid PID --batch -ex 'info symbol HEX_SYMBOL_ADDR'
I have a core file from embedded SH3 linux device, and gdb of the cross compiler environment (sh3-linux-gdb) in my host linux.
But I have problems loading the core file with gdb:
$ sh3-linux-gdb ./myprogram ./core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
...
This GDB was configured as "--host=i386-pc-linux-gnu --target=sh3-linux"...
GDB can't read core files on this machine.
(gdb)
Why it can't read the core file?
Is there any way to read the core file from target system to the cross gdb?
There is gdbserver in target machine (SH3-linux), but not gdb itself.
I am able to do runtime debuging of processes of target machine with gdbserver and sh3-linux-gdb, so sh3-linux-gdb should be correctly compiled.
EDIT:
readelf dump was requested:
[build]$ sh3-linux-readelf -a core
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: CORE (Core file)
Machine: Renesas / SuperH SH
Version: 0x1
Entry point address: 0x0
Start of program headers: 52 (bytes into file)
Start of section headers: 0 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 51
Size of section headers: 0 (bytes)
Number of section headers: 0
Section header string table index: 0
There are no sections in this file.
There are no sections in this file.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NOTE 0x000694 0x00000000 0x00000000 0x00200 0x00000 0
LOAD 0x001000 0x00400000 0x00000000 0x00000 0x01000 R E 0x1000
----- several boring lines removed -----
LOAD 0x05a000 0x29952000 0x00000000 0x01000 0x01000 RW 0x1000
LOAD 0x05b000 0x7be48000 0x00000000 0x15000 0x15000 RWE 0x1000
There is no dynamic section in this file.
There are no relocations in this file.
There are no unwind sections in this file.
No version information found in this file.
Notes at offset 0x00000694 with length 0x00000200:
Owner Data size Description
CORE 0x000000a8 NT_PRSTATUS (prstatus structure)
CORE 0x0000007c NT_PRPSINFO (prpsinfo structure)
CORE 0x000000a0 NT_AUXV (auxiliary vector)
[build]$
EDIT2: Same problem with --core option:
$ sh3-linux-gdb ./myprogram --core=./core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i386-pc-linux-gnu --target=sh3-linux"...RUN GDB INIT
GDB can't read core files on this machine.
(gdb)
Try according to http://forums.freescale.com/t5/68K-ColdFire-reg-Microprocessors/GDB-can-t-read-core-files/td-p/70181
sh3-linux-gdb ./myprogram --core=./core
It may be a bug in the old gdb http://sourceware.org/bugzilla/show_bug.cgi?id=9542 - so try newer gdb (7) too.
Also possible that core was dumped in unsupported format. What is target's OS, version?
Can you post the output or readelf -a core ?
It is possible to debug your application, not with gdb directly but with gdb server. The first thing you have to do is to call gdbserver in the target system (you said in your question that this package is already installed) :
gdbserver AAA.BBB.CCC.DDD:port ./myprogram
It is assume that the target machine is accessible to an IP address : AAA.BBB.CCC.DDD:port. Once, you have done that, you can call gdb in your development machine by specifying the target remote server :
% gdb ./myprogram
% [...]
(gdb) target remote AAA.BBB.CCC.DDD:port
Note that the target remote server IP address are the same of the gdbserver.