I am working on valgrind and want to debug a program while valgrind runs over it.
But i don't want to use the in built vgdb, instead i want to use a custom gdb server.
Is there a way to plugin this custom gdbserver in the existing valgrind code.
thanks
Only by patching valgrind. The valgrind gdbserver implementation is compiled in.
Related
Our projects all use CMake, and Fabric seems to require a script run in XCode's build environment to extract information. CMake doesn't seem to have a way to add a run script build phase.
So, I tried running the script manually after setting the following manually from known values in CMake:
INFOPLIST_PATH
BUILT_PRODUCTS_DIR
DWARF_DSYM_FILE_NAME
DWARF_DSYM_FOLDER_PATH
PROJECT_DIR
As a result, there were no errors when running the script but ..also nothing happened. I just got a "Launching uploader in validation mode" and then the process exited.
Is it possible I could get a full run-down of what the program needs in order to run? Our projects are built on a build server so having to VNC in and launch xcode to build is not really an option.
Thanks in advance.
Since you're using CMake, instead of using the run script build phase, I'd use the upload-symbols script as that will be a more reliable way to upload the dSYMs to Crashlytics.
I tried to generate an executable code for my program but it always crashes. It was okay in release / debug mode. This is the only change I have done based on the website http://xoax.net/cpp/crs/visualcpp/lessons/CreateExe/
When choosing release configuration the run time library should be Multi-Threaded.
In debug configuration you should choose Multi-Threaded Debug.
I'm doing some experiments with an evaluation version of the WindRiver dcc diab compiler. I would like to do some testing on my Windows PC.
However I think I have the wrong target setup.
I've got as far as using the 'dctrl -t' command to get the list of target architectures, but selecting options so far hasn't produced anything i can run on windows.
I'm simply doing:
dcc main.c -o main.exe
Am I missing a step?
do I have the wrong target?
or is it simply not possible to create windows binaries?
I believe that the Diab compiler targets a free-standing environment, so would not produce a Windows executable. Moreover x86 is not a supported target processor in any case; see the product brief.
The compiler is intended for use with VxWorks, though can be separately licensed. The toolchain includes an instruction-set simulator for executing target code in a simulated environment, and if you are using VxWorks, that includes a VxWorks simulator.
If you want to build your code as a native Windows application; you will have to use a Windows targeted compiler. I suggest MinGW/GCC since WindRiver support both their own WindRiver/Diab compiler and GCC for Vxworks development, and they share a great deal of commonality with respect to compiler switches and extension syntax.
We have a storage controller that is used as target, it runs MIPS and has some additional hardware that goes with it. Development is done with Green Hills Compiler. Can we use VALGRIND to perform analysis on the code base ?
If your target is not running Linux or an OS with a POSIX API it is unlikely that you will be able to build and execute Valgrind natively. One possibility is to build your embedded code on Linux in a suitable test harness and execute tests on that.
I have a problem which I have been struggling with for a while.
I have a Cocoa library which acts as a wrapper for a C++ library. C++ library is tested using a set of BOOST unit tests. The tests run normally under both debug and release modes.
In order to test the Cocoa wrapper I am using otest. Here is the strange part, the tests run normally in debug mode but fail in release mode. To make sure its not something in the code I've taken the tests content and compiled them as a separate Cocoa app which uses the wrapper code. This runs normally both under release and debug.
When otest fails I get a stack trace which makes little sense and ends with dyld_misaligned_stack_error.
Another strange thing that I've noticed is that when starting otest from a command line rather than from XCode if I point DYLD_LIBRARY_PATH and DYLD_FRAMEWORK_PATH to the Debug version of C++ library the tests pass. I have confirmed though that all my test code is being compiled with Release flags.
Any help would be greatly appreciated!
Thank you
Try adding flag "-mstackrealign" in C flags in the release version.
-mstackrealign
Realign the stack at entry. On the Intel x86, the -mstackrealign
option will generate an alternate prologue/epilogue that realigns
the runtime stack. This supports mixing legacy codes that keep a
4-byte aligned stack with modern codes that keep a 16-byte stack
for SSE compatibility.
See GCC's man page for reference.