I have a debugger connected to a Linux box as follows:
[Debugger] <- usb -> [Machine A] <- tcp -> [Rendezvous server] <- tcp -> [Laptop]
I can start st-util on Machine A, forward the :4242 port to the Laptop and connect it as follows:
laptop$ arm-none-eabi-gdb target extended-remote localhost:4242
Connection is successful and I can flash the microcontroller.
However, when I need to debug, gdb keeps saying value has been optimized out.
What is wrong with my setup? Isn't forwarding the server port enough for remote debugging?
Edit
I didn't think this is a compiler optimization issue because it wasn't present while I was debugging with direct connection. However, I installed the necessary toolchain on the Machine A but the result is the same. Here is the make output:
/home/ceremcem/embedded/gcc/gcc-arm-none-eabi-10-2020-q4-major/bin//arm-none-eabi-gcc -c -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -DUSE_HAL_DRIVER -DSTM32F407xx -ICore/Inc -IDrivers/STM32F4xx_HAL_Driver/Inc -IDrivers/STM32
F4xx_HAL_Driver/Inc/Legacy -IDrivers/CMSIS/Device/ST/STM32F4xx/Include -IDrivers/CMSIS/Include -Imodbus_lib -Og -Wall -fdata-sections -ffunction-sections -Wextra -g -gdwarf-2 -MMD -MP -MF"build/main.d" -Wa,-a,-ad,-alms=build/main.lst Core/Src/main.c -o build/main.o
As we can see, the -Og option is used and it is suitable for debugging purposes:
Optimize debugging experience. -Og should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience. It is a better choice than -O0 for producing debuggable code because some compiler passes that collect debug information are disabled at -O0.
Like -O0, -Og completely disables a number of optimization passes so that individual options controlling them have no effect. Otherwise -Og enables all -O1 optimization flags except for those that may interfere with debugging: (...)
Solution
(moved to answer)
Despite the documentation and my previous experience, I used -O0 instead of -Og as the build option and voila, the debugger just printed what I expected.
Related
Using clang or clang++ the command of
clang -S -emit-llvm ./source.c
will create a llvm ir document. However debugging information is missing. So when you test and compile things you lose debugging information.
How does one can make clang emit human readable llvm ir document with debug information ?
The standard option to add debug info is -g. So, running clang -g -S -emit-llvm source.c will emit necessary information
Our security team has a new code scanner that requires the gcc -g3 -gdwarf-2 build options. We normally use -ggdb3. Before I change our default build, I want to make sure this does not negatively impact the debug information or generated executable code. From the documentation it is hard to tell the difference. Does anyone have any insight on the differences between these two options? I'm building on a CentOS 7 distribution with gcc 4.8.
From a brief read of the man page -ggdb3 will
use the most expressive format available ( DWARF 2, stabs, or the native format if neither of those are supported), including GDB extensions if at all possible.
whereas -g3 -gdwarf-2 will
Produce debugging information in DWARF format (if that is supported).
This is the format used by DBX on IRIX 6. The value of version may be either 2 or 3;
the default version is 3.
Note that with DWARF version 2 some ports require, and will always use,
some non-conflicting DWARF 3 extensions in the unwind tables.
So it seems like -ggdb3 may produce non DWARF 2 debugging info in certain cases and the -g3 -gdwarf-2 will ensure that DWARF 2 is used.
EDIT: The -g3 is needed because -gdwarf-x does not support appending the debug level to it where as -ggdb does support appending a debug level.
I have a C application running on embedded ARM M4; it works correctly.
I use Kinetis Design Studio, which uses gdb, as my debugger on Windows.
For most of my .obj, I can single-step the C source. However, for a few files, although I can use breakpoints, single-stepping the C source doesn't work: pressing Single-step causes debugger to act as if I pressed Run but the app is definitely not running.
But single-stepping the assembly, same .obj files, works correctly.
I use the same compile options for all .c
-x c -Wall -Werror -std=c99 -nostdlib -mthumb -mtune=cortex-m4 -mlittle-endian -Wdouble-promotion -DNDEBUG -fdata-sections -ffunction-sections -c -save-temps=obj -g3 -gdwarf-2
QUESTION
For some .obj, why do the breakpoints and assembly single-step work but not the source single-step?
You could provide some more information and what you tried so far. For example, what is the difference in those object files? Are it always the same? Do they have specific dependencies to non-user-code or are they non-user-code? What are you debugger-options? Based on that, I can just give basic advice:
-Check the correctness of your symbol file configuration / that they are in sync with the binary and loaded correctly.
-Be sure that there are no changes to the source code after compilation, so the IDE cannot falsely shows code that does not exist in you latest compilation (which is not debuggable).
-Consider to deactivate options like JustMyCode - depending on your environment (https://learn.microsoft.com/de-de/visualstudio/debugger/just-my-code?view=vs-2017)
-Check your debugger options
I'm trying to follow this tutorial
http://gnuarmeclipse.livius.net/blog/test-project/
to run a GNU ARM hello world.
I'm using eclipse luna on windows 8.1 x64.
I've installed the GNU ARM toolchain, and everything else the tutorial states.
The build passes, and gives the result specified in the tutorial
> 02:15:01 **** Build of configuration Debug for project ARMTest4 ****
> make all Building file: ../src/main.c Invoking: Cross ARM C Compiler
> arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -O0 -fmessage-length=0
> -fsigned-char -ffunction-sections -fdata-sections -g3 -std=gnu11 -MMD -MP -MF"src/main.d" -MT"src/main.o" -c -o "src/main.o" "../src/main.c" Finished building: ../src/main.c Building target: ARMTest4.elf
> Invoking: Cross ARM C Linker arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb
> -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -g3 -Xlinker --gc-sections -Wl,-Map,"ARMTest4.map" --specs=rdimon.specs -Wl,--start-group -lgcc -lc -lc -lm -lrdimon -Wl,--end-group -o "ARMTest4.elf" ./src/main.o Finished building target: ARMTest4.elf Invoking: Cross ARM GNU Create Flash Image
> arm-none-eabi-objcopy -O ihex "ARMTest4.elf" "ARMTest4.hex" Finished
> building: ARMTest4.hex Invoking: Cross ARM GNU Print Size
> arm-none-eabi-size --format=berkeley "ARMTest4.elf" text data
> bss dec hex filename 8256 2396 260 10912
> 2aa0 ARMTest4.elf Finished building: ARMTest4.siz
>
> 02:15:06 Build Finished (took 5s.110ms)
Then, I try to run, and it fails, I have no idea why. It says "Error starting process"
The details in the error box state
> Error starting process. Cannot run program
> "C:\Users\Noam\workspace\cpp\ARMTest3\Debug\ARMTest3.elf": Launching
> failed Cannot run program
> "C:\Users\Noam\workspace\cpp\ARMTest3\Debug\ARMTest3.elf": Launching
> failed Cannot run program
> "C:\Users\Noam\workspace\cpp\ARMTest3\Debug\ARMTest3.elf": Launching
> failed
The only thing I can come up with is the code is supposed to run on some emulator and not my PC, which i have no idea how to do.
If this isn't the problem, please tell me what is.
I have also tried many other configurations for the hello world project, to no success.
My expected output for a working result: some console saying "Hello ARM world" to me.
Thanks.
You can't run ARM executables on an x64 processor. The tutorial expects you to have an ARM system available, like an emulator or a Raspberry Pi.
I can't make comments yet, so this is actually a follow up to wavemode's answer:
The quickest way to set up an emulator is with (depending on your platform) VirtualBox, or QEMU. Install Linux(or another OS that supports ARM binaries) into the image and boot from it. You'll need to transfer the binary to the emulated system, for example by SSH or HTTP.
Finding ARM images is relatively easy, and Debian, Fedora, ArchLinux, and others all provide pre-made images.
As others have stated, the GNU ARM tools are intended to target an external ARM microprocessor or microcontroller and the compiled programs will not run on your workstation.
There are a great number of ARM-based chips and development boards from several manufacturers that can be used with the GNU ARM tools and the idea is usually to create your own system with an embedded microcontroller. The program will need to be adapted for the specific microcontroller and board you are using.
The tutorial isn't clear, but the "Prerequisites" page linked from the tutorial has a section "Assign a device to the project", with a screenshot showing STM32F4-Discovery/STM32F407VG circled - I would assume the author is using that board.
The STM32 Discovery boards are low-cost (some under US$20), and include an ST-Link programmer/debugger and interesting peripherals to learn with. Other manufacturers usually have similar development boards featuring their parts.
I'm building some large project using GCC 4.4.2. Since I want to build it for release, I use -O1 GCC optimization flag, but unluckily it messes somehow with my code, and the final binaries do not work as expected, when building with -O0 flag (or no optimization) everything works fine.
I had a similar problem with my project before, in that time it was the -fstrict-aliasing flag that caused troubles on -O2 optimization level, I managed to find that it was caused by that specific flag by making a search on all flags that are mentioned in this documentation, regarding the -O2 optimization level:
http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Optimize-Options.html
Now I tried to do the same with the list they mention regarding the -O1 flag, but unfortunately it seems that not all the flags mentioned, or there are some hidden flags being enabled, because when I compile with just -O1 flag or with just a list of the provided flags (without putting -O1 itself) I get different compilation results, and my binaries refuse to work only with the specific -O1 flag, so I can't find the exact troublemaking option.
Is it possible to know what hidden options the -O1 option includes, and how can I disable some of them?
You can run gcc -Q -v on a small C file to have GCC dump the options being used.
Run it with and without the -O1 option to get the difference between the enabled options.