we are using Sun Solaris for our application development and compiling 64 bit application by using -m64.
But the 32 bit GDB tool has been installed in my machine and we are unable to debug our 64 bit application.
The output as
$ gdb cxlog
GNU gdb 6.8
Copyright (C) 2008 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 "sparc-sun-solaris2.10"...
(gdb) break main
Breakpoint 1 at 0x100001464: file cxlogger.c, line 147.
(gdb) run
Starting program: /usr33/SIR07140/GTB_HOME/GoTx_HOME/samples/cxlog
procfs:4337 -- process not stopped.
procfs: ...giving up...
(gdb) n
procfs: couldn't find pid 12372 (kernel thread 1) in procinfo list.
(gdb).
normal debugging commends like next & step are not working.
If I compile my application by using -m32 GDB is working file.
Thanks in Advance.
Sundar Rajendran.
You basically have three choices - in order of my preference:
Install 64-bit GDB on the machine.
Rebuild your app in 32-bit mode and debug that way.
Build your own version of gdb, for 64-bit targets, from sources.
The only way you'll debug a 64-bit binary is to have a gdb that is built for 64-bit [or some other debugger, but whichever it is, it needs to be built for 64-bit targets]
Related
I am cross-compiling a C / C++ application to run on a Raspberry Pi 4 with the arm-rpi-4.9.3-linux-gnueabihf compiler from the Tools Github Repository on an x64 Debian Linux system running in a VM. I am having some issues with this application so I built Valgrind from source on the Raspberry Pi with GCC 8.3.0-++rpi1.
The compiler binaries I am using can be downloaded here: https://github.com/raspberrypi/tools/tree/master/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf
If I run Valgrind on the RPI I get a number of errors, many of which indicate "Invalid read of size 8". My understanding is this would be typical on 64-bit architecture (8*8 = 64) but may be misleading on this 32-bit system unless the application was accessing a 64-bit data structure. Also, running Valgrind on the same application, built for and running on an x64 system, does not identify errors at these same locations, which makes me think that either the compilation toolchain is introducing an ABI issue or that Valgrind is giving misleading error indications -- or both.
Valgrind also indicates on startup:
--3451-- Arch and hwcaps: ARM, LittleEndian, ARMv8-neon-vfp
--3451-- Page sizes: currently 4096, max supported 4096
However $ uname -m indicates: arm7l, which I understand to be 32 bit (and definitely not ARMv8).
Can anyone provide any guidance on what might be going wrong here?
Thanks!
In this term, I have Microprocessors lectures and we're working on ARM Development with C/C++ and Assembly.
For a while I've been looking for an alternative for Keil uVision which is compatible with Linux Distributions (now using Arch) and able to assemble ARM and flash, but could not find anything. The most related platform was Eclipse but it does not look supports ARM Assembly and nothing that I read about flashing to STM32.
I don't want to work on Windows for ARM Development, is there any way to assemble ARM and flash it?
Very simple. Install STM32CubeIDE for linux and nucleotides board with your preferred STM32 uC. Follow the tutorials online
Be aware that Keil uses ARM's own compiler version 5 or 6 (current releases of Keil MDK support both v5 being ARM's legacy ARMCC, and 6 is based on clang/llvm). If you are following a course, and the course material is based on a different toolchain, you may encounter difficulties - or worse your tutor may not be able to mark your work. Just a consideration before you go off-piste.
Linux solutions are likely to be GNU toolchain based. An ARM GNU toolchain for Cortex-M can be found at: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm.
Flashing STM32 may either be done through a JTAG/SWD debugger usually using OpenOCD, or via the on-chip bootloader using a tool such as http://manpages.ubuntu.com/manpages/bionic/man1/stm32flash.1.html. Your hardware debugger vendor may have their own Linux driver, so worth checking. Mbed compatable boards present as a USB mass-storage device and can be flashed simply by copying the image file drive.
Building and flashing on Linux is only half the battle however; you will presumably want to debug your code too. GDB with OpenOCD or a proprietary driver will of course work, but raw GDB is not a pleasant experience, and you might want to have a more "visual" debug solution. IDEs such as STM32CubeIDE integrate the toolchain, flashing and debugging - but is specific to STM32.
I am wishing to debug 32 bit nacl exe on mac platform. I couldnt debug it out since on mac platform i couldnt find a 32bit nacl-gdb. Has anyone successfully done it?
GDB for Native Client was released in Pepper 23, so first check that you're using the Pepper 23 version of the NaCl SDK or newer. (To download any new versions of the SDK, issue ./naclsdk update from your nacl_sdk directory. When it's done, you should see a pepper_23 directory (or newer). Use the tools in that directory.)
In the SDK the GDB binaries are in these locations (example based on Pepper 23):
nacl_sdk/pepper_23/toolchain/mac_x86_glibc/bin/i686-nacl-gdb
nacl_sdk/pepper_23/toolchain/mac_x86_glibc/bin/x86_64-nacl-gdb
nacl_sdk/pepper_23/toolchain/mac_x86_newlib/bin/i686-nacl-gdb
nacl_sdk/pepper_23/toolchain/mac_x86_newlib/bin/x86_64-nacl-gdb
The two i686-nacl-gdb are in fact just symbolic links to the two x86_64-nacl-gdb. The x86_64-nacl-gdb binaries will allow you to debug both 32-bit and 64-bit x86 NaCl targets. On the Mac, though, Chrome is always 32-bit and will always run the 32-bit .nexe, even if your OS or machine is 64-bit.
Both the newlib and the glibc toolchain contains a complete set of tools; this is why you have two x86_64-nacl-gdb binaries. Currently, these two do not differ, but for your own sanity it's probably easiest to use the GDB in the same directory as the tools used for your build.
There is some additional guidance at https://developers.google.com/native-client/devguide/devcycle/debugging#gdb. The all-important thing is to pass the flag --enable-nacl-debug to Chrome or activate it under about:flags in Chrome. This will cause Chrome to wait for the debugger to connect before executing Native Client content.
Is there a way to speed up gdb when it loads a very large c++ binary?
The binary I am talking about is about 50MB in a release build (no debug symbols)
A debug build is bigger then 400MB and gdb needs more then 2 minutes to load it.
Maybe there are some settings that speed up loading the application into gdb ?
Any help is very appreciated!
Environment: ubuntu karmic 64bit with gdb v6.8, 32GB Ram, 8 cpu-cores
Begin by upgrading to GDB 7.0.1. GDB developers have spent quite a bit of effort in 2009 making GDB 7.0 faster (and there is more to come in 7.1 :-)
I am trying to build gdb for armv6 architecture. I will be compiling this package on a Fedora Linux-Intel x86 box. I read the process of installing the gdb, like
Download the source pachage
run configure -host
make
But I got lost in the process because I was not able to make out what will be the host, target, needed for the configure script.
I need to basically be able to debug programs running on armv6 architecture board which runs linux kernel 2.6.21.5-cfs-v19. The gdb executable which I intend to obtain after compilation of the source also needs to be able to run on above mentioned configuration.
Now to get a working gdb executable for this configuration what steps should I follow?
We (www.rockbox.org) use the arm target for a whole batch of our currently working DAPS. The target we specify is usually arm-elf, rather than arm-linux.
Be careful with arm-linux vs. arm-elf, eg.
http://sources.redhat.com/ml/crossgcc/2005-11/msg00028.html
arm-elf is a standalone toolchain which does not require an underlying OS. So you can use
it to generate programs using newlib
arm-linux is a toolchain targetted to generate code for linux OS running on an ARM machine
We sometimes say arm-elf is for "bare metal".
Unfortunately there's another "bare metal" target arm-eabi and no one knows what the difference between these two exactly is.
BTW,
The gdb executable which i intend to obtain after compilation of the source,also needs to be able to run on above mentioned configuration.
Really? Running GDB on an ARM board may be quite slow.
I recommend you either of
Remote debugging of the ARM board from an x86 PC
Saving a memory core on the ARM board, transferring it to an x86 PC and then inspecting it there
Cf.
http://elinux.org/GDB
Cross-platform, multithreaded debugging (x86 to ARM) with gdb and gdbserver not recognizing threads
http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/remote-debugging
target/host is usually the target tool chain you would be using (mostly arm-linux)