Building and debugging ARMV8 assembler applications on Windows - arm

I'm trying to learn ARMV8 assembler, and am trying to build a test application on Windows. I've installed ARM DS-5 Community Edition, version 5.26.2. After much hair pulling trying to install toolchains, I finally installed the "mingw32" toolchain here: here. This seems to work - I am now able to compile and link my application (which consists of a single c file and a .s assembly file. The target created is a ".axf" file.
But I am unable to debug. I have my debugger set to "\gcc-linaro-6.3.1-2017.02-i686-mingw32_aarch64-linux-gnu\bin\aarch64-linux-gnu-gdb.exe", out of the directory where I downloaded the toolchain. gdb starts up, but I get the error below:
Error in final launch sequence
Failed to execute MI command:
-exec-run
Error message from debugger back end:
Don't know how to run. Try "help target".
Don't know how to run. Try "help target".
Any suggestions? Frankly, I don't really know what I'm doing here. I'm not sure I set up the toolchain properly. The problem is I can't find any documentation on how to do this in windows.
Thanks in advance!

Related

Can't launch debug - C in VS code on Linux

Let me preface this, I am very new to linux and to working on a non-IDE based setup.
I am trying to debug a very simple C program using vs code version 1.55
I unloaded all modules beforehand, so vs code can load appropriate default gcc & gdb versions (which it did, GCC 8.2)
I am following the VS code getting started documentation for setting up and everything seems very straight forward until I try to debug.
I use the default settings as instructed, the file builds successfully but then I get the below
/usr/bin/gdb: symbol lookup error: /usr/bin/gdb: undefined symbol: PyUnicodeUCS4_FromEncodedObject
please note that I cannot rebuild python with ucs4 enabled as suggested in another thread as I have no root access. however I can change VS code version to an earlier one if this will help.
Thanks.
I think this issue is specific to my environment but I will post the answer anyway as it may face someone else.
So this for me was 2 separate issues:
First gdb doesn't start and second vs code can't start gdb.
To check if this is the case try to launch gdb from terminal (not vs code) by typing gdb in the terminal (after loading gdb if needed), I was receiving the error above
Solution to this part is this as T0maas thankfully suggested above
Steps for linux newbies:
ldd gdb (or /usr/bin/gdb) (with vs_code loaded)
from step one get the python library path
unload all modules
load gdb
LD_PRELOAD=<python path from 1>
bash -c "export LD_PRELOAD"
load vs_code
load gdb
After the above steps writing gdb in the terminal should start gdb
Part 2:
The rest of the problem was when I tried to launch debugging session through the GUI of vs_code (still produced the same error)
In the terminal (after loading gdb) type whereis gdb
For me this produced multiple directories the first of which was /usr/bin/gdb (this is the default used in vs_code launch.json)
Changing that directory in the launch.json file to a different one of the other directories solved the second part of the problem for me.

Configure GDB to accept Cross-Compiled executables?

I'm still a newbie to assembly language and cross-compiling etc. I've already googled the problem I'm having and seen a few similar posts but none of them solved my problem unfortunately.
We're learning ARM32 Syntax at the university and playing around with assembly code on AARCH64 machines on a uni server. So we need to cross-compile the .s files to be able to run them.
We use the command arm-linuxgnueabihf-gcc to cross-compile.
Now the system (the loader I guess) is configured properly to execute these 32-bit cross executables. When I tried to debug a 32b exec however GDB crashes with error: selected architecture armv7 is not compatible with reported target architecture aarch64
There are screenshots below that illustrate the problem. Thanks for any help!
System infos:
System info
No error with native compiler:
No error with native compiler
Error with cross-compilation:
Error with cross-compilation

debugging error "interpreter `mi2' unrecognized" with eclipse

Debugging with eclipse ide I get this error:
"Error in services launch sequence. Interpreter `mi2' unrecognized."
This was all working a month ago so for some reason it has stopped.
I know mi2 is something to do with GDB.
Code is built using gcc-8.3.0-2019.08.0, using Freedom Studio SiFive Eclipse IDE for C/C++ Development
Version: 4.12.0.2019-08-2
I realise this is a bit niche so any suggestions welcome
Solution:
Recreate Project using Freedom-E SDK Software Project for my project - which was e310 arty (I had selected the wrong one in starting the project).
When debugging use configuration for "SiFive GDB OpenOCD Debugging."
This seemed to work.

Eclipse C/C++ does not want to run an app, outputting an Error -.-

Alright, hello guys. I've been using Eclipse Luna for some time now while programming in Java. Recently, due to school work, I decided to download the C/C++ for the eclipse as well. I have installed it and all went well. Then I wrote a simple programme and Eclipse will not run it.
Each time there is a pop up: Launch failed. Binary not found.
Also, Eclipse says there is the following error: Program "make"not found in PATH.
Now, I have tried everything to fix it. I'm using the MinGW. I also downloaded Msys.I added all the necesarry paths into the System enviroment variables and done the same thing in the Eclipse.
I went into the Window -- Preferences -- C/C++ -- New C/C++ project and under Binary Parsers selected the PE Windows Parser. I've tried other things as well, like adding the following line into the eclipse.ini as someone suggested:
-DMINGW_HOME=C:\Program Files (x86)\CodeBlocks\MinGW
Nothing seems to be working though and I sadly cannot run even the simplest of programs. Haalp, please.
Kind regards,
George.

Eclipse mac osx: Launch failed, binary not found

Just installed eclipse on my mac cannot run my projects when i build and run i get the following message: launch failed, binary not found.
I've set on project setting \macosx gcc\ and linker\miscellaneus\flags -arch i686
doesnt work, i am pretty stuck.
Hi I ran into a similar problem. I am using the following build :
Eclipse IDE for C/C++ Developers
Version: Juno Service Release 2
The fix go into Project > Properties > C/C++ Build > Settings > Binary Parsers : Make sure "Mach-O 64 Parser is selected"
This thread helped me out: "Launch Failed. Binary Not Found." Snow Leopard and Eclipse C/C++ IDE issue
"THE PROBLEM: is that GCC 4.2 (the GNU Compiler Collection) that comes with Snow Leopard compiles binaries in 64-bit by default. Unfortunately, the linker that Eclipse uses does not understand 64-bit binaries; it reads 32-bit binaries. There may be other issues here, but in short, they culminate in no binary being generated, at least not one that Eclipse can read, which translates into Eclipse not finding the binaries. Hence the error."
The fix go into Project > Properties > C/C++ Build > Settings > Binary >Parsers : Make sure "Mach-O 64 Parser is selected"
I made sure this was correct, and still recieved an error, so I would say the best solution is to do this step...then, BUILD the project, then press the "play" button and it should work (that is what fixed my problem)
You must build it first, then click run. It will be fine then.
You need to select the proper binary parser so Eclipse can recognize the executable :
Select the project, then
Project->Properties->C/C++ Build->Settings->Binary Parsers
For the mac select Mach-O Parser.
I wish CDT just came with these selected, it’d be a simple plug-n-play setup. If nothing else they could add a hint in the error text.
I had the same issue,
although i changed the parser as above mentioned it didn't work and i got the same error.
In addition, building the project via the menu solved the problem:
Project>Build All
I guess the very first code execution with eclipse makes it necessary to build the code separately before pressing the green run button (as i supposed this at least compiles the code).

Resources