Many of the instrumentation options for gcc save data to a file during/after runtime:
When the compiled program exits it saves this data to a file called auxname.gcda for each source file.
However, I'm running on a custom C++-based RTOS which doesn't have a filesystem "natively" like Linux.
QUESTION
How do I use these gcc-instrumentation options that output results to a file?
Do I have to provide a file-writer interface - which in my case would write to a RAM buffer - which would be called whenever the instrumentation code needs to "write to file"?
A web search for "gcc gprof arm-cortex-m" produces: https://mcuoneclipse.com/2015/08/23/tutorial-using-gnu-profiling-gprof-with-arm-cortex-m/
It appears to use semihosting to write profiling data to host machine.
Semihosting is a common way for ARM to communicate with debugger on host (through JTAG/SWD). It is also supported on emulators like qemu.
Related
I have an image compiled successfully for a mobile device. I now want to run it on another device. Can I potentially use the compiled binary? I do not care about having all the functionality right now. I just want to call one of the functions in the code and get a response.
Is it possible to add the compiled code as a shared library in a JNI project?
#Alex - Thank.
Your library is built for some runtime, e.g. iOS or Linux or Windows. It cannot run on a different type of system, but usually quite easily runs on another device of the same kind.
I need to do unit testing for drivers in an arm based board with the help of gcov tool.When gcov is used in a x86 architecture it will create .gcda file after executing the program.But when it comes to an arm based board the .gcda files are not getting created.So,without that i couldn't use the gcov tool.My question is how to use that gcov tool in cross compilation.?.Thanks in advance.
gcov code/data structures are tied to host filesystem and cross-compiler toolchains do not have any port or a configuration to change this behavior. If your object file is ~/my-project/abc.o then the gcov in-memory data structures created/updated by the instrumented code point to ~/my-project/abc.gcda, and all these paths are on your host machine. The instrumented code running on the remote system (in your case the ARM board), as you can see, cannot access these paths and this is the main reason you don't see the .gcda files in the ARM board case.
For a general method on getting the .gcda files to get around this above issue, see https://mcuoneclipse.com/2014/12/26/code-coverage-for-embedded-target-with-eclipse-gcc-and-gcov/. This article presents a hacky method to break into gcov functions and manually dump the gcov data structures into on-host .gcda files.
I used the above mentioned blog to do code coverage for my ARM project. However; I faced another issue of a gcc bug in my version of the toolchain (the GNU arm toolchain version available in October/November 2016), where you would not be able to break into gcov functions and complete the process mentioned in the above blog, as the relevant gcov functions hang with an infinite loop. You may or may not face this issue because I am not sure if the bug is fixed. In case you face this issue, a solution is available in my blog https://technfoblog.wordpress.com/2016/11/05/code-coverage-using-eclipse-gnu-arm-toolchain-and-gcov-for-embedded-systems/.
I'm using CDT to remotely debug an application. The application constructs a
source fragment and JITs it into memory. For debugging, it creates an in-memory
ELF/DWARF image and registers it with the GDB JIT interface, and writes a source
file corresponding to the DWARF, to the local (target) filesystem.
The problem is that the debugger front-end then expects to find the source file on
the host filing system. If I manually copy the source file from the target to the
host after every JIT event then the debugger can step through the source, but this
is impractical. Having the JIT upload the file to the host would need the JIT to
be aware it was being debugged (and from where). Is there a way to get gdbserver,
or CDT, to retrieve the source file, when needed, from the target filesystem?
I create the ELF/DWARF image that is passed to the GDB JIT interface, so I could
describe the source file location using an alternative path if that would help.
The gdbserver protocol already supports fetching remote files.
The trick then is to have GDB issue fetch command automatically in response to JIT events. This would be quite easy to do using Python scripting. Unfortunately, it looks like JIT events are not exposed to Python.
I suggest filing a feature request in GDB bugzilla.
Say I have a build machine and test machine and the source code is only on the build machine. (Linux)
I have a debug build C/C++ executable and I want to run it with gdb on the test machine.
In the debugger running on the test machine it is still looking for the actual source files which are not there.
Is there a way to have g++ actual include the source in the executable itself with the other debug information so files are not needed?
There is no way to have the source compiled into the binary to allow gdb debugging in this manner.
Probably the best mechanism in this case is to use gdbserver - which allows you to run the application remotely and debug it on the build machine.
If you can't use remote debugging, then an alternative is to mount the directory containing the source on the test machine, and then use the set substitute-path to map the directory that the test machine has vs. the build machine.
No, but the good news is that is no necessary. You should set your source path. It should accept a network path.
I want to create a program that modifies another c++ source,compiles it and runs the exe.
I mean with something like gcc may be I can but on a windows os gcc may not be present.
Is it possible?
I think your options are fairly limited for windows:
Check for an install of a compiler (possibly limit this to a short list) and use that compiler
Bring along a compiler in your application's install package
Cowboy answer:
Only if:
the source code doesn't need a lot of files/headers/libraries
they can be easily collected by your application
the application have connection with some server of yours
The application could:
collect the files in a zip
send them over the wire to an compiler service (accesible vía HTTP)
the server compile it with its own installation
and return the binary executable inside the response.
Of course: it depends on so many variables that seems not very feasible. And the zip+http thing could be difficult from a C/C++ app.