This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
I am attempting to debug a 64-bit program but gdb seems to think it has an i386 architecture.
# file /usr/local/bin/foo
/usr/local/bin/foo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.4.0, not stripped
# gdb --args foo bar
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 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 "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/bin/foo...done.
(gdb) set debug arch 1
(gdb) show debug arch
Architecture debugging is 1.
(gdb) info target
Symbols from "/usr/local/bin/foo".
Local exec file:
gdbarch_find_by_info: info.bfd_arch_info i386:x86-64
gdbarch_find_by_info: info.byte_order 1 (little)
gdbarch_find_by_info: info.osabi 5 (GNU/Linux)
gdbarch_find_by_info: info.abfd 0xaf4a90
gdbarch_find_by_info: info.tdep_info 0x0
gdbarch_find_by_info: Previous architecture 0xb05790 (i386:x86-64) selected
`/usr/local/bin/foo', file type elf64-x86-64.
Entry point: 0x419730
0x00000000004001c8 - 0x00000000004001e4 is .interp
0x00000000004001e4 - 0x0000000000400204 is .note.ABI-tag
0x0000000000400208 - 0x0000000000402560 is .hash
0x0000000000402560 - 0x0000000000409898 is .dynsym
0x0000000000409898 - 0x0000000000411188 is .dynstr
0x0000000000411188 - 0x0000000000411b22 is .gnu.version
0x0000000000411b28 - 0x0000000000411b88 is .gnu.version_r
0x0000000000411b88 - 0x00000000004181a0 is .rela.dyn
0x00000000004181a0 - 0x0000000000418e78 is .rela.plt
0x0000000000418e78 - 0x0000000000418e90 is .init
0x0000000000418e90 - 0x0000000000419730 is .plt
0x0000000000419730 - 0x00000000004ede38 is .text
0x00000000004ede38 - 0x00000000004ede46 is .fini
0x00000000004ede48 - 0x00000000004ede4c is .eh_frame
0x00000000006ee000 - 0x00000000006ee010 is .ctors
0x00000000006ee010 - 0x00000000006ee020 is .dtors
0x00000000006ee020 - 0x00000000006ee028 is .jcr
0x00000000006ee028 - 0x00000000006ee1f8 is .dynamic
0x00000000006ee1f8 - 0x00000000006f07f0 is .got
0x00000000006f07f0 - 0x00000000006f0c50 is .got.plt
0x00000000006f0c50 - 0x0000000000736c70 is .data
0x0000000000736c70 - 0x000000000073b420 is .bss
(gdb) start
Temporary breakpoint 1 at 0x419e70: file foo.lpr, line 69.
Starting program: /usr/local/bin/foo bar
warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386
gdbarch_find_by_info: info.bfd_arch_info i386:x86-64
gdbarch_find_by_info: info.byte_order 1 (little)
gdbarch_find_by_info: info.osabi 5 (GNU/Linux)
gdbarch_find_by_info: info.abfd 0xaf4a90
gdbarch_find_by_info: info.tdep_info 0x0
gdbarch_find_by_info: Target rejected architecture
gdbarch_update_p: Architecture not found
warning: Architecture rejected target-supplied description
gdbarch_find_by_info: info.bfd_arch_info i386:x86-64
gdbarch_find_by_info: info.byte_order 1 (little)
gdbarch_find_by_info: info.osabi 5 (GNU/Linux)
gdbarch_find_by_info: info.abfd 0xd6ce90
gdbarch_find_by_info: info.tdep_info 0x0
gdbarch_find_by_info: Previous architecture 0xb05790 (i386:x86-64) selected
Error in re-setting breakpoint 1: Cannot access memory at address 0x419e60
Error in re-setting breakpoint 1: Cannot access memory at address 0x419e60
process 5299 is executing new program: /usr/local/bin/foo
warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386
gdbarch_find_by_info: info.bfd_arch_info i386:x86-64
gdbarch_find_by_info: info.byte_order 1 (little)
gdbarch_find_by_info: info.osabi 5 (GNU/Linux)
gdbarch_find_by_info: info.abfd 0xb21790
gdbarch_find_by_info: info.tdep_info 0x0
gdbarch_find_by_info: Target rejected architecture
Architecture of file not recognized.
Note the warning:
warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386
and then:
gdbarch_find_by_info: Target rejected architecture
gdbarch_update_p: Architecture not found
warning: Architecture rejected target-supplied description
In gdb, if I type 'set architecture' and hit tab, I see the following:
(gdb) set architecture
auto i386:intel i386:x64-32:intel i386:x86-64:intel
i386 i386:x64-32 i386:x86-64 i8086
My question is: why does gdb think my file has an i386 architecture even though it is obviously an x86-64 binary and what can I do to fix it?
My program was compiled using FreePascal version 2.6.0.
UPDATE:
I do not get any warnings using the same gdb binary and the same freepascal binary on my Ubuntu 12.04 machine (with a 3.2.0-31 kernel). The server I am attempting to debug on is running a 2.6.34.10-24 kernel. Could something be misconfigured in the kernel or on the server that would affect gdb?
Your problem starts here:
gdbarch_find_by_info: Target rejected architecture
This means that target-dependent code in GDB didn't like something about the i386:x86-64 architecture. Unfortunately there is no easy way to tell what it didn't like -- you'll have to debug GDB itself to find that out.
Can you debug other binaries (e.g. /bin/date) on the machine where GDB fails?
Related
I'm using Devtoolset-7 on CentOS 7 and have built Boost 1.65.1 w/ it.
But when I link my application, I've got the following:
/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/ld: /opt/rh/devtoolset-7/root/usr/lib64/libboost_unit_test_framework.a(compiler_log_formatter.o)(.text._ZN5boost9unit_test5utils11string_castINS0_13basic_cstringIKcEEEESsRKT_[_ZN5boost9unit_test5utils11string_castINS0_13basic_cstringIKcEEEESsRKT_]+0x3c): unresolvable R_X86_64_NONE relocation against symbol `_ZTVSt9basic_iosIcSt11char_traitsIcEE##GLIBCXX_3.4'
/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
Searching more info about R_X86_64_NONE doesn't give any valuable results: mostly similar questions w/o any answer or precise explanation what is this and how to solve it.
So my questions are:
what is this error really means?
what is R_X86_64_NONE and why "nothing to relocate" (according to bintils sources) type of symbol ever exists in ELF headers?
Addendum:
The error happened on linking unit tests executable which is linked against my static library and Boosts' static libraries (unit tests framework)
All static libraries (Boost and mine one) has built with -fPIC option
PS. I really want this question to be resolved once and forever (already hit it few times, but this time update to latest binutils doesn't help). (will start a bounty on any activity on this question)
From the build log posted to the Red Hat Bugzilla bug:
[19:15:01]W: [Step 8/12] + /usr/lib/rpm/check-buildroot
[19:15:01]W: [Step 8/12] + /usr/lib/rpm/brp-scl-compress /opt/rh/devtoolset-7/root
[19:15:01]W: [Step 8/12] + /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
[19:16:40]W: [Step 8/12] /usr/bin/strip: /work/build/BUILDROOT/devtoolset-7-boost-1.65.1-4.el7.centos.x86_64/opt/rh/devtoolset-7/root/usr/lib64/libboost_container.a(global_resource.o): invalid relocation type 42
[19:16:40]W: [Step 8/12] /usr/bin/strip: BFD version 2.25.1-32.base.el7_4.2 assertion fail elf64-x86-64.c:341
Note /usr/bin/strip, not /opt/rh/devtoolset-7/root/usr/bin/strip. So the system strip command is used. 42 corresponds to the R_X86_64_REX_GOTPCRELX relocation, which is generated by DTS binutils as an optimization.
A simple way to reproduce this is with this C++ file:
#include <iostream>
void
dot ()
{
std::cout << '.';
}
If compile with -O2 -fpic, it will produce an X86_64_REX_GOTPCRELX relocation for _ZNSt8ios_base4InitD1Ev. Running /usr/bin/strip -g on that will turn that into R_X86_64_NONE. This can be verified using eu-readelf -r.
You can use RPM to tell to use the DTS strip using
%if 0%{?scl:1}
%define __strip %{_bindir}/strip
%endif
in the RPM spec file, or you can add
%undefine __brp_strip_static_archive
to skip stripping the static library completely (which is probably the right thing to do anyway).
In our code we trying to catch an exception. This code has been working fine for years with different architectures and operating systems (x86, x64, SuSe Linux 11 SP2, Oracle 11g, Oracle 12c). Now we also tried out Solaris 11.3 on x86/64 and Sparc with Oracle 12c.
It turns out that we are not able to catch the exceptions and that the whole program crashes. We produce a shared object library which is then loaded into Oracle and used by a stored procedure. Within that stored procedure we might throw an exception but catch it and make it pretty for Oracle.
The combination of Solaris 11.3/Oracle 12c/x64 now behaves strange:
The extproc process is being killed and Oracle just delivers an ORA-28576: lost RPC connection to external procedure agent error message.
Please find an MVCE at https://gist.github.com/pgab/13ac10f4302d11cab45ba80584eeca0f.
The complete output on Solaris with SQL Developer is:
declare
ret number;
begin
"thrower".test_throw(ret);
end;
Error report -
ORA-28576: lost RPC connection to external procedure agent
ORA-06512: at "thrower.TEST_THROW", line 1
ORA-06512: at line 4
28576. 00000 - "lost RPC connection to external procedure agent"
*Cause: A fatal error occurred in either an RPC network connection,
the extproc agent, or the invoked 3GL after communication had
been established successfully.
*Action: First check the 3GL code you are invoking; the most likely
cause of this error is abnormal termination of the
invoked "C" routine. If this is not the case, check for
network problems. Correct the problem if you find it. If all
components appear to be normal but the problem persists, the
problem could be an internal logic error in the RPC transfer
code. Contact your customer support representative.
Also the used /tmp/debug.log produces just:
about to throw
In comparison the output with SuSe is:
declare
ret number;
begin
"thrower".test_throw(ret);
end;
Error report -
ORA-20001: foo
ORA-06512: at "thrower.TEST_THROW", line 1
ORA-06512: at line 4
And in /tmp/debug.log
about to throw
foo
To be even more confusing:
The same code works perfectly fine on Solaris 11.3 on Sparc,
A single executable is able to throw and catch exceptions properly.
Which bit am I missing here? Maybe it a special linker flag or something else which needs to be activated for Solaris or even for Oracle?
Edit:
With the hint of #Andrew Henle I was digging into compiler and linker versions being used within extproc and the library being produced using strings -a and scanning the output:
On Solaris liboragst contained the following strings (c.f. https://nopaste.xyz/?63251ef69b12e0ac#zgE4Hfagu08eBnSkbIWKcV/Zoux9X6UWw+AH2eGESxM=):
GNU C++ 4.8.2 -m64 -mtune=generic -march=x86-64 -g -fPIC
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.2458
where as extproc (the process spawned by Oracle RDBMS to load the external procedure) contains this (c.f. https://nopaste.xyz/?913cef4a7fdd4c0d#cHkGRMpWn3IiFwpqv0auys4nn04wfrwtom3eIHEimLE=):
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.2329
Xa;O;p;F;R=Sun C 5.12 SunOS_i386 Patch 148918-06 2013/06/11;backend;raw;cd;
/opt/SunProd/studio12u3/solarisstudio12.3-148906-08/prod/bin/cc
But there is nothing at /opt/SunProd/studio12u3 being installed.
Furthermore please find below the versions of gcc/g++ and ld:
Solaris:
g++ --version
g++ (GCC) 4.8.2
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.
ld --version
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.2458
2nd Edit:
I have no managed to compile the library with Oracle's developerstudio but still get an ORA-28576 error instead of the wanted ORA-20001. It is a "clean" Solaris 11.3 installation with just Oracle Database, CMake and Developer Studio 12.6.
Cmake issues:
/opt/developerstudio12.6/bin/CC -DoraGST_EXPORTS -fpic -m64 -std=c++03 -g -KPIC -I/export/opt/ora12cg3d/product/12.1.0/dbhome_1/rdbms/public -o CMakeFiles/oraGST.dir/oGST_manual.cpp.o -c /export/home/paul/test/oGST_manual.cpp
and
/opt/developerstudio12.6/bin/CC -KPIC -fpic -m64 -std=c++03 -g -m64 -std=c++03 -G -hliboraGST.so -o liboraGST.so CMakeFiles/oraGST.dir/oGST_manual.cpp.o -lstdc++
ldd -d liboraGST.so yields:
libstdc++.so.6 => /opt/developerstudio12.6/lib/compilers/CC-gcc/lib/amd64/libstdc++.so.6
libgcc_s.so.1 => /opt/developerstudio12.6/lib/compilers/CC-gcc/lib/amd64/libgcc_s.so.1
libstatomic.so.1 => /opt/developerstudio12.6/lib/compilers/atomic/amd64/libstatomic.so.1
libCrunG3.so.1 => /usr/lib/64/libCrunG3.so.1
libm.so.2 => /lib/64/libm.so.2
librt.so.1 => /lib/64/librt.so.1
libc.so.1 => /lib/64/libc.so.1
For you reference you can find the output of strings -a at https://nopaste.xyz/?50daded482074bd3#9KLZaMYDiVBEFLLrTFV1UOY5ZRaZWnz006iBwSnCzMk=
I am trying to figure out a very strange issue. I have CentOS 6.5 system with gdb:
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-75.el6)
and gcc:
gcc (GCC) 4.8.2 20131212 (Red Hat 4.8.2-8)
I have this file:
#include<stdio.h>
int main()
{
printf("OK!");
return 0;
}
which I compile with:
gcc -o a a.c -g -O0
The file seems to be fine:
$ file a
a: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
But when I try to debug it, this happens:
$ gdb a
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-75.el6)
Copyright (C) 2010 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 "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from a...done.
(gdb) b main
Breakpoint 1 at 0x4004e4
(gdb) r
Starting program: a
Breakpoint 1, 0x00000000004004e4 in main ()
(gdb) l
1 /* Run time dynamic linker.
2 Copyright (C) 1995-2006, 2007, 2008, 2009, 2010 Free Software Foundation, Inc.
3 This file is part of the GNU C Library.
4
5 The GNU C Library is free software; you can redistribute it and/or
6 modify it under the terms of the GNU Lesser General Public
7 License as published by the Free Software Foundation; either
8 version 2.1 of the License, or (at your option) any later version.
9
10 The GNU C Library is distributed in the hope that it will be useful,
(gdb) l main
No line number known for main.
I.e., gdb refuses to see any debug information. Anybody has an idea what could be a problem here?
Your GDB is pretty old. Your GCC is fairly new.
I suspect that your GCC is emitting DWARF4 debug info (default as of gcc-4.8 according to release notes), which your GDB does not recognize.
Do you get better result with -gdwarf-2 instead of -g?
If so, upgrade your GDB or use -gdwarf-2 with this compiler.
GNU gdb Fedora (6.8-37.el5)
Kernal 2.6.18-164.el5
I am trying to debug my application. However, everytime I pass the binary to the gdb it says:
(no debugging symbols found)
Here is the file output of the binary, and as you can see it is not stripped:
vid: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
I am compiling with the following CFLAGS:
CFLAGS = -Wall -Wextra -ggdb -O0 -Wunreachable-code
Can anyone tell me if I am missing some simple here?
The most frequent cause of "no debugging symbols found" when -g is present is that there is some "stray" -s or -S argument somewhere on the link line.
From man ld:
-s
--strip-all
Omit all symbol information from the output file.
-S
--strip-debug
Omit debugger symbol information (but not all symbols) from the output file.
The application has to be both compiled and linked with -g option. I.e. you need to put -g in both CPPFLAGS and LDFLAGS.
Some Linux distributions don't use the gdb style debugging symbols. (IIRC they prefer dwarf2.)
In general, gcc and gdb will be in sync as to what kind of debugging symbols they use, and forcing a particular style will just cause problems; unless you know that you need something else, use just -g.
You should also try -ggdb instead of -g if you're compiling for Android!
Replace -ggdb with -g and make sure you aren't stripping the binary with the strip command.
I know this was answered a long time ago, but I've recently spent hours trying to solve a similar problem. The setup is local PC running Debian 8 using Eclipse CDT Neon.2, remote ARM7 board (Olimex) running Debian 7. Tool chain is Linaro 4.9 using gdbserver on the remote board and the Linaro GDB on the local PC. My issue was that the debug session would start and the program would execute, but breakpoints did not work and when manually paused "no source could be found" would result. My compile line options (Linaro gcc) included -ggdb -O0 as many have suggested but still the same problem. Ultimately I tried gdb proper on the remote board and it complained of no symbols. The curious thing was that 'file' reported debug not stripped on the target executable.
I ultimately solved the problem by adding -g to the linker options. I won't claim to fully understand why this helped, but I wanted to pass this on for others just in case it helps. In this case Linux did indeed need -g on the linker options.
Hope the sytem you compiled on and the system you are debugging on have the same architecture. I ran into an issue where debugging symbols of 32 bit binary refused to load up on my 64 bit machine. Switching to a 32 bit system worked for me.
Bazel can strip binaries by default without warning, if that's your build manager. I had to add --strip=never to my bazel build command to get gdb to work, --compilation_mode=dbg may also work.
$ bazel build -s :mithral_wrapped
...
#even with -s option, no '-s' was printed in gcc command
...
$ file bazel-bin/mithral_wrapped.so
../cpp/bazel-bin/mithral_wrapped.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=4528622fb089b579627507876ff14991179a1138, not stripped
$ objdump -h bazel-bin/mithral_wrapped.so | grep debug
$ bazel build -s :mithral_wrapped --strip=never
...
$ file bazel-bin/mithral_wrapped.so
bazel-bin/mithral_wrapped.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=28bd192b145477c2a7d9b058f1e722a29e92a545, not stripped
$ objdump -h bazel-bin/mithral_wrapped.so | grep debug
30 .debug_info 002c8e0e 0000000000000000 0000000000000000 0006b11e 2**0
31 .debug_abbrev 000030f6 0000000000000000 0000000000000000 00333f2c 2**0
32 .debug_loc 0013cfc3 0000000000000000 0000000000000000 00337022 2**0
33 .debug_aranges 00002950 0000000000000000 0000000000000000 00473fe5 2**0
34 .debug_ranges 00011c80 0000000000000000 0000000000000000 00476935 2**0
35 .debug_line 0001e523 0000000000000000 0000000000000000 004885b5 2**0
36 .debug_str 0033dd10 0000000000000000 0000000000000000 004a6ad8 2**0
For those that came here with this question and who are using Qt: in the release config there is a step where the binary is stripped as part of doing the make install. You can pass the configuration option CONFIG+=nostrip to tell it not to:
Instead of:
qmake <your options here, e.g. CONFIG=whatever>
you add CONFIG+=nostrip, so:
qmake <your options here, e.g. CONFIG=whatever> CONFIG+=nostrip
The solutions I've seen so far are good:
must compile with the -g debugging flag to tell the compiler to generate debugging symbols
make sure there is no stray -s in the compiler flags, which strips the output of all symbols.
Just adding on here, since the solution that worked for me wasn't listed anywhere. The order of the compiler flags matters. I was including multiple header files from many locations (-I/usr/local/include -Iutil -I. And I was compiling with all warnings on (-Wall).
The correct recipe for me was:
gcc -I/usr/local/include -Iutil -I -Wall -g -c main.c -o main.o
Notice:
include flags are at the beginning
-Wall is after include flags and before -g
-g is at the end
Any other ordering of the flags would cause no debug symbols to be generated.
I'm using gcc version 11.3.0 on Ubuntu 22.04 on WSL2.
Below details are from a session in a Sun machine running Solaris 10.
$ file devli
devli: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped
$ file a
a: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped
$ gdb
GNU gdb 6.4
Copyright 2005 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 "sparc-sun-solaris2.10".
(gdb) file a
Reading symbols from /tmp/tnmy/a...(no debugging symbols found)...done.
(gdb) file devli
"/tmp/tnmy/devli": not in executable format: File format not recognized
(gdb) q
$ ls -l a devlisrvr
-rwxr-xr-x 1 test2 dba 1480 Dec 23 18:23 a
-rwxr-xr-x 1 test2 dba 633088 Dec 23 18:26 devli
$ uname -a ;
SunOS myhost 5.10 Generic_127111-11 sun4v sparc SUNW,SPARC-Enterprise-T5220
$ cat a.c
int main() {return 0;}
$ /opt/SUNONE8/SUNWspro/bin/CC -V
CC: Sun C++ 5.5 2003/03/12
$ file `which gdb`
/usr/local/bin/gdb: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped
$
Any details on why would not gdb recognize the file format for devli? I searched over the Internet but could not find anything related to this particular issue. Any pointers would be helpful.
a.c goes into a, built using gcc; devli using Sun ONE Studio 8.
Note that GDB 6.4 is 4 years old. You might get better luck with (current) GDB 7.0.
It is also possible that the devli executable is corrupt (file just looks at the first few bytes of the executable, but GDB requires much more of the file contents to be self-consistent). Does readelf --all > /dev/null report any warnings?