I'm attempting to get the nacl-gdb working with one of the example applications provided with the nacl_sdk. In particular, I'm trying to get it working with the sample hello_tutorial application in the getting_started/part1 folder (the stub code from this tutorial: https://developers.google.com/native-client/dev/devguide/tutorial/tutorial-part1).
I've tried following the instructions here: https://developers.google.com/native-client/dev/devguide/devcycle/debugging#debugging-with-nacl-gdb
But whenever I connect to the target, gdb prints out the following:
(gdb) target remote localhost:4014
Remote debugging using localhost:4014
warning: Can not parse XML target description; XML support was disabled at compile time
0x00000000 in ?? ()
I can then continue and the application runs, but it it's very helpful without the debugging symbols. Anybody know why this might not be working properly?
I performed the following steps:
Modified the Makefile to build hello_tutorial.pexe without finalizing it, and added the -g flag when compiling, and re-ran make.
Ran pnacl-translate to create the .nexe files from the un-finalized .pexe.
../../toolchain/linux_pnacl/bin/pnacl-translate --allow-llvm-bitcode-input hello_tutorial.pexe -arch x86-64 -o hello_tutorial_x86_64.nexe
Modified the hello_tutorial.nmf to point to the nexe files instead of the pexe file.
Modified index.html to point to "application/x-nacl", instead of "application/x-pnacl"
Started Chrome with the following command:
/opt/google/chrome/chrome --enable-nacl --enable-nacl-debug --no-sandbox --disable-hang-monitor localhost:5103
Start up the debugger from the part1 folder with the following command:
../../toolchain/linux_x86_newlib/bin/x86_64-nacl-gdb
Ran the following commands from within gdb. (Note that it shows "no debugging symbols found" when reading from the nacl_irt_x86_64.nexe - is that a problem?)
(gdb) nacl-irt hello_tutorial_x86_64.nexe
Reading symbols from /home/bender/dev/nacl_sdk/pepper_33/getting_started/part1/hello_tutorial_x86_64.nexe...done.
(gdb) nacl-irt /opt/google/chrome/nacl_irt_x86_64.nexe
Reading symbols from /opt/google/chrome/nacl_irt_x86_64.nexe...(no debugging symbols found)...done.
(gdb) target remote localhost:4014
Remote debugging using localhost:4014
warning: Can not parse XML target description; XML support was disabled at compile time
0x00000000 in ?? ()
I'm running on Linux:
Linux bender-VirtualBox 3.11.0-18-generic #32-Ubuntu SMP Tue Feb 18 21:11:14 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Looks like this is working okay if I use pepper_canary instead of pepper_33. Found some info at this link: https://code.google.com/p/nativeclient/issues/detail?id=3739
Related
I'm having issues when trying to debug a cross compiled binary on my WSL2 host and only end up with backtraces with addresses in ?? (), any hint's on what to verify and change are welcome!
file mybin shows:
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=..., with debug_info, not stripped
The application is started in WSL2 via qemu-i386(based on output from ps)
NOTE: I was wondering a bit about this because in my prev dev env using vm-ware and ubuntu 18.04 i was not seeing qemu-i386 used but did not think more about it based on WSL2 issues regarding 32bit application support referring to qemu and binfmt solving it.
I'm running gdb-multiarch (GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2)
Loading the executable and listing symbols with info functions <a_regex> works fine but when attaching and breaking i get bt's like this (NOTE output below is taken from VSCode with a few logging flags enabled, hence the -exec bt thing for example):
-exec bt
1: (777701) <-1183-interpreter-exec console "bt"
1: (777704) ->~"#0 0x000000000047a4ea in ?? ()\n"
1: (777707) ->~"#1 0x00007ffd2dcdb1c0 in ?? ()\n"
1: (777709) ->~"#2 0x0000000000467efc in ?? ()\n"
1: (777711) ->~"#3 0x0000000000000000 in ?? ()\n"
NOTE: When attaching i get the following warning:
warning: Selected architecture i386 is not compatible with reported target architecture i386:x86-64
setting architecture to i386:x86-64 is accepted by gdb but makes no difference
Setting a breakpoint gives the following error:
1: (40020) ->&"Cannot insert breakpoint 1.\n"
1: (40020) ->&"Cannot access memory at address 0xbce346f\n"
1: (40020) ->&"\n"
1: (40023) ->^error,msg="Command aborted."
UPDATE: SOLVED
Thought installing gcc-multilib solved it but it seems more likely the issue was because of a bug in Docker Desktop which has been fixed in v3.2.2. See description in my own answer below.
The qemu-i386 thing was bugging me so I decided to try compiling a simple .c with -m32 flag to check if it also would trigger being run via qemu, got errors because I was missing gcc-multilib so I installed it.
Started the buildt binary and noticed that it did not run via qemu-i386.
Started my original application again and this time it did also not start via qemu.
Started gdb-multiarch, loaded the bin and attached to the process and now suddenly everything worked fine, got a nice proper backtrace!
I'm currently running a file manager program that abruptly crashed with a segmentation fault and dumped a core file. So I used gdb to debug the core file as:
gdb /path/to/executable /path/to/core
The program which I was running is written in C++. When I ran GDB and tried to print the source lines using "list", I got the following error:
(gdb) bt
#0 0x0000000000554286 in
MyFSEventManager::AddEvent(wxFileSystemWatcherEvent&) ()
#1 0x00000000005ab2e8 in
MyGenericDirCtrl::OnFileWatcherEvent(wxFileSystemWatcherEvent&) ()
(gdb) f 0
#0 0x0000000000554286 in
MyFSEventManager::AddEvent(wxFileSystemWatcherEvent&) ()
(gdb) l
1 /build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmain.c: No such file or directory.
Why does gdb say this "/build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmain.c: No such file or directory." I do not hit this issue with some other programs that I've debugged using gdb.
The operating system used is Ubuntu 16.04 running on Oracle virtual box. I think may be the gdb symbols were not loaded. I'm not sure why since I compiled the program using the "-g" option. I really need to know the source lines where the code crashes via gdb.
Any suggestions?
EDIT: changes after suggestions from Employed Russian
I was compiling my main using "-g" option and linking it to "existing" object files which were obviously not compiled using "-g" so when the core dumped, I could not see the source for these files. So I went ahead and recompiled those files with "-g" option and reproduced the core dump. It's able to show me the source lines now.
Why does gdb say this "/build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmain.c: No such file or directory."
Because you really don't have that file on your system.
I think may be the gdb symbols were not loaded
GDB did load debug symbols for glib, but not for your main executable.
I'm not sure why since I compiled the program using the "-g" option.
Since we don't have your compile and link lines, we can't tell exactly what's wrong, but some of the common issues are:
You have a "stray" -s or -Wl,-s on your link line (this strips debug info from the resulting binary).
You have -g when compiling your main.c, but not when compiling the source in which MyFSEventManager::AddEvent() is defined
P.S.
(gdb) bt
This doesn't seem to be the complete output from bt command. Always try to paste complete outputs as it makes helping easier :)
Before explaining my problem:
My OS is Ubuntu 12.04 LTS 32bits with 4GB RAM.
My IDE is Code::Blocks 12.11(I've had the same problem with 10.05)
I'm using the GNU GCC Compiler with the -g flag and the -std=c++0x flag.
When trying to debug this program:
using namespace std;
#include<iostream>
int main(){
int n=10;
for(int i=1;i<=n;i++){
int ax=i;
while(ax) ax--;
cout<<i;
}
return 0;
}
I can't get anything to happen,if I try the "Run to cursor" command or if I try to use breakpoints. They just get skipped and my program finishes running.
This is what I get in the debugger log:
Building to ensure sources are up-to-date
Selecting target:
Release
Adding source dir: /home/classius/CodeBlocks/Dr/
Adding source dir: /home/classius/CodeBlocks/Dr/
Adding file: /home/classius/CodeBlocks/Dr/bin/Release/Dr
Changing directory to: /home/classius/CodeBlocks/Dr/.
Set variable: LD_LIBRARY_PATH=.:
Starting debugger: /usr/bin/gdb -nx -fullname -quiet -args /home/classius/CodeBlocks/Dr/bin/Release/Dr
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Reading symbols from /home/classius/CodeBlocks/Dr/bin/Release/Dr...(no debugging symbols found)...done.
Debugger name and version: GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
No symbol table is loaded. Use the "file" command.
Temporary breakpoint 2 ("/home/classius/CodeBlocks/Dr/main.cpp:10) pending.
[Inferior 1 (process 13381) exited normally]
Debugger finished with status 0
If anyone wants to suggest a solution that implies using the terminal, please do it in the most noob-orieted terms you can find!
PS: How to add breaklines on stack-overflow when asking a question?(Solved-Thanks!)
Reading symbols from /home/classius/CodeBlocks/Dr/bin/Release/Dr...(no
debugging symbols found)...done.
This means you didn't have the -g option during compilation.
UPDATE:
file /home/classius/CodeBlocks/Dr/bin/Release/Dr
/home/classius/CodeBlocks/Dr/bin/Release/Dr: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x7da8c5cff4af5082d82eecc3ede59a5920b253a0, stripped
So it's 'stripped', which means -g option was not really used. You may recheck your compiler config or try to build the Debug version?
in settings menu choose debugger then gdb-cdb tab and then reset default
I'm working on RHEL WS 4.5.
I've obtained the glibc source rpm matching this system, opened it to get its contents using rpm2cpio.
Working in that tree, I've created a patch to mtrace.c (i want to add more stack backtrace levels) and incorporated it in the spec file and created a new set of RPMs including the debuginfo rpms.
I installed all of these on a test vm (created from the same RH base image) and can confirm that my changes are included.
But with more complex executions, I crash in mtrace.c ... but gdb can't find the debug information so I don't get line number info and I can't actually debug the failure.
Based on dates, I think I can confirm that the debug information is installed on the test system in /usr/src/debug/glibc-2.3.6/
I tried
sharedlibrary libc*
in gdb and it tells me the symbols are already loaded.
My test includes a locally built python and full symbols are found for python.
My sense is that perhaps glibc isn't being built under rpmbuild with debug enabled. I've reviewed the glibc.spec file and even built with
_enable_debug_packages
defined as 1 which looked like it might influence the result. My review of the configure scripts invoked during the rpmbuild build step didn't give me any hints.
Hmmmm .. just found /usr/lib/debug/lib/libc-2.3.4.so.debug
and /usr/lib/debug/lib/tls/i486/libc-2.3.4.so.debug
but both of these are reported as stripped by the file command.
It appears that you are installing non-matching RPMs:
/usr/src/debug/glibc-2.3.6
just found /usr/lib/debug/lib/libc-2.3.4.so.debug
There are not for the same version; there is no way they came from the same -debuginfo RPM.
both of these are reported as stripped by the file command.
These should not show as stripped. Either they were not built correctly, or your strip is busted.
Also note that you don't actually have to get all of this working to debug your problem. In the RPMBUILD directory, you should be able to find the glibc build directory, with full-debug libc.so.6. Just copy that library into your VM, and you wouldn't have to worry about the debuginfo RPM.
Try verifying that debug info for mtrace.c is indeed present. First see if the separate debug info for GLIBC knows about a compilation unit called mtrace.c:
$ eu-readelf -w /usr/lib/debug/lib64/libc-2.15.so.debug > t
$ grep mtrace t
name (strp) "mtrace.c"
name (strp) "mtrace"
1 0 0 0 mtrace.c
[10480] "mtrace.c"
[104bb] "mtrace"
[5052] symbol: mtrace, CUs: 446
Then see if GDB actually finds the source file from the glibc-debuginfo RPM:
(gdb) set pagination off
(gdb) start # pause your test program right after main()
(gdb) set logging on
Copying output to gdb.txt.
(gdb) info sources
Quit GDB then grep for mtrace in gdb.txt and you should find something like /usr/src/debug/glibc-2.15-a316c1f/malloc/mtrace.c
This works with GDB 7.4. I'm not sure the GDB version shipped with RHEL 4.5 supports all the command used above. Building upstream GDB from source is in fact easier than Python though.
When trying to add strack traces to mtrace, make sure you don't call malloc() directly or indirectly in the GLIBC malloc hooks.
I have just moved from Ubuntu 10.04 to the new version of 11.04 and when I try to debug with ddd/gdb I cannot set anymore breakpoints nor see the flow while the debugger is executing my program.
I receive error messages saying
(gdb)b MyFile.cpp:27
No line 27 in file "MyFile.cpp".
When I start running my application calling r I also can see the following text message that looks to me related to my issue. The debuggers traps all assertions but I cannot stop at any point.
(gdb) r
BFD: /lib/x86_64-linux-gnu/libc.so.6: invalid relocation type 37
BFD: BFD (GNU Binutils) 2.18.50.20080226 assertion fail elf64-x86-64.c:278
BFD: /lib/x86_64-linux-gnu/libc.so.6: invalid relocation type 37
BFD: BFD (GNU Binutils) 2.18.50.20080226 assertion fail elf64-x86-64.c:278
If I want to see the file, the debuggers open the file with me but I receive the following error message
(gdb) list MyFile.cpp:27
Line number 27 is out of range for "MyFile.cpp".
Can you help me?
I read some forum asking to check the result of info source and info sources and this is what I have but I don't know what to do with it.
(gdb) list MyFile.cpp:27
Line number 27 is out of range for "MyFile.cpp".
(gdb) info source
Current source file is /usr/local/include/boost/exception/exception.hpp
Compilation directory is /home/emanueler/trunk/tools/myAppBinary
Located in /usr/local/include/boost/exception/exception.hpp
Contains 436 lines.
Source language is c++.
Compiled with unknown debugging format.
Includes preprocessor macro info.
Why it says "Compiled with unknown debugging format." when I am giving the -g option at compiler?
It seems all the compiling related tools were also updated, including GCC. It would be best if you recompile your entire application in this new environment before trying to debug it again.
You can do a simple test for check that your toolchain is ok. Write a small hello world app, compile it with -g and try to set a breakpoint on the cout line.