why does gdbserver support tracepoint when it is not supported in gdb? - gdb

i wonder if gdb has some difficulties in supporting tracepoints.
have seen some answers on stack overflow. just mention that "tracepoint facility is currently available only for remote targets."(answered in 2010)

why does gdbserver support tracepoint when it is not supported in gdb?
Most likely because nobody bothered.
After all, you can always use gdbserver even for local debugging, so it you want tracepoints, just do that?

Related

Linux to Windows C++ port [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I am trying to port my C++ application from Linux to Windows (Visual C++).
I am just curious wheter you know about any script/tool that would scan the source code and check for possible issues (such as dirent.h etc).
Thanks.
The first tool is called your compiler. It will tell you if your program compiles.
The second tool is called running whatever tests you may have. They will tell you if the resulting binary works.
What were you looking for, a crystal ball to save you from doing work? Regardless of what approach you take or what you may read to help you get started, you will at some point have to (1) compile the thing and (2) check to see that it works.
Microsoft has an entry on the MSDN about the 'best' ways to manage a port from *nix to Win32.
http://msdn.microsoft.com/en-us/library/y23kc048.aspx
http://www.mingw.org/wiki/msys or http://www.cygwin.com/
edit:
Cygwin is essentially a compatibility layer (implemented as a dll) between Unix/Posix and windows - the code should be unchanged, but there can be issues between different version of the cygwin dll.
Msys+Mingw is a subset of Unix/Posix libs reimplemented in win32 and a port of the gcc compiler plus essential build tools. The resulting exe runs completely natively but some complex build procedures need more work.
Either way if the app uses X then you also need an X-server, both of these provide one. But if you are doing lots of graphics and the app is written using something like Qt or wxWidgets you are going to have a reasonable amount of pain getting it to work.
First, I would just compile using MinGW (at least at first), to eliminate any possible gcc to MSVS issues (not to waste time with compiler-related issues).
Second, just compile the code and watch all the include files that were not found. Go to the code that includes those headers, figure out if it is a dependency that exists in Windows (but was just not installed or set in include-paths). If not, use cross-platform libraries to replace the non-portable libraries. Typical cross-platform libraries would include: Boost, OpenGL, SDL, Qt, etc. (depending on how much your application is doing). If it is just a command-line "number-crunching" software, you will probably find all you need in Boost.

profiling in solaris

Can anyone suggest a good tool to profile a program compiled with SunCC compiler.
Also please suggest a good equivalent of valgrind for the same.
DTrace is the best tool for profiling [in] the universe.
DTrace is a comprehensive dynamic
tracing framework for the Solaris™
Operating Environment. DTrace provides
a powerful infrastructure to permit
administrators, developers, and
service personnel to concisely answer
arbitrary questions about the behavior
of the operating system and user
programs.
It's not marketing, it really allows just that.
The Solaris Dynamic Tracing Guide
describes how to use DTrace to
observe, debug, and tune system
behavior. The DTrace guide also
includes a complete reference for
bundled DTrace observability tools and
the D programming language.
DTrace is also available in Mac OS X, (there's a nice GUI for it, Instruments), and a FreeBSD port that has only kernel mode providers is also available.
The Sun Studio compilers include Performance Analyzer for profiling and Memory Runtime Checking features in the dbx debugger.
See also the answers to Locate bad memory access on Solaris.
On SPARC hardware, you may want consider IBM Rational Quantify for performance profiling.
On the cheap, you can get away with pstack sampling, prstat -vL, and instrumenting your application with gethrtime().

XCode debugger sucks; alternatives? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I've been programming on the Mac since I was a little kid using THINK C. I've never had to use a debugger as bad as the one that comes with XCode.
It's unresponsive, and bogs down further and becomes unstable when watching more variables.
When it crashes, I lose undo history for my sources because it's integrated with the editor.
It doesn't benefit from integration, though, as the source viewer is unusable for stepping: Trying to select a line by clicking on the left margin makes a button appear from nowhere which causes to program to continue to that line, in the editor window, which shouldn't relate to debugging in the first place. Horrible UI and horrible implementation.
A hobbled pretty-data "summary" syntax which can't send an object to the Expressions window.
he Expressions window isn't aware of any kind of context, ever.
Can't select a particular thread to debug, far as I can tell, and doesn't jump to the thread that called abort().
The kernel debugger for Mac OS 9 was better than this. It's time to give up.
What standalone front-ends for GDB work on OS X? I found http://ddd.darwinports.com/ but it's hard to find praise or anecdotes for it, or other alternatives.
Support for STL containers is a big plus for me. I couldn't care less about Objective-C or Apple-anything.
I tend to use valgrind for memory related errors;
gdb (in a teminal) when I want a backtrace;
and logging + couts for all else (if it's not crashing, and there's no memory corruption, the bug seems easier).
Admittedtely, no idea how to debug multi threaded code.
Have you tried monodevelop? It can build and debug C code, Not show how it handles obj-c.
If you can get DDD working I have used that with good results on many strange platforms. DDD requires X11.
I've had the same experience with XCode, and ended up switching to Netbeans and Eclipse (still not sure which one I prefer over the other, both have strong and weak points).
This may seem an odd choice, but both of them offer nice C++ support, reasonable debugger integration, and good project management options. I enjoy the refactoring tools and the source version control integration as well. Mind that they are not as snappy and clean as Visual Studio 6.
As many others here, I do not like Objective-C, and am pretty much fed-up with having to learn different environment/frameworks for each platform I write for (I use Linux and OSX daily, Windows on occasion). Both Netbeans and Eclipse are a big plus for portability. They also support other languages that I use sometimes for smaller projects (Python comes to mind).
I add to what anon said that I found also this trick on SO recently that allows easier STL debugging:
$ cd ~
$ svn co svn://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python
$ cat ~/.gdbinit
python
import sys
sys.path.insert(0, '/home/USERNAME/python/')
from libstdcxx.v6.printers import register_libstdcxx_printers
register_libstdcxx_printers (None)
end
I just discovered cgdb, a curse based frontend for gdb. Maybe you'll want to give it a try, although it seems a bit outdated. (Jan'10)

Is there any C++ API available to know the OS description?

I am working on tools that will be used on the multiple OSes and platforms. These tools will provide the details of the OS on which it is running, like 32-bit or 64-bit OS, exact version of Linux, Solaris, or other OS.
One way I am thinking is of using the "uname -a" command to extract the OS information on a Linux/Unix-based OS. Please suggest me that if it is efficient to call the command from the program.
Is there any API available or is there any workaround that I can implement?
Note that I also do need to check for OS information on the Windows.
Why don't you simply wrap the OS detection with #define and each time call the ideal function so as to return a meaningful string in every case?
Some examples of system function to get information about the current OS (such as the running version):
In Windows the function is:
GetVersionEx
FreeBSD (and unixes I guess): uname
The C++ Standard Library provides no way of doing this, so you are at the mercy of operating system specific features. And even then, there is no general method, as utilities like "uname" are not supported on Windows and will give differently formatted results on different UNIX flavours.
You can give a try to sysinfo() call (from sys/systeminfo.h on Unix).
Also regarding "uname -a" efficiency, it depends where are you going to use it. In normal circumstances (if your application is not time/CPU critical) performance of "uname -a" should be acceptable.
There is also a function, "uname()", present in the sys/systeminfo.h file, which may help you.
There is no standard way to do this. But you can apply fingerprinting techniques to find out the target OS.
These are generally used to guess remote machine OS. You can look at Nmap also. It does various types of fingerprintings.
I would think that uname -a would be a good way, but only for *nixes.

Free memory debugger for Windows? [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is there a good Valgrind substitute for Windows?
I am looking for a free memory debugger for Windows, suited for debugging C++ applications built with VC, with similiar functionality to Insure++ or Purify.
Any recomendations?
GUI is a plus
Integration with VS is a bigger plus
Ollydbg is also pretty useful.
valgrind + cygwin
ANSIMD (Ansi Memory Debugger)
UPS Debugger
GoBug Debugger
Microsoft Debugging Tools
Stack Trace Analysis Tool (STAT)
Mono Migration Analysis
http://www.debuginfo.com/ - Might be some of tools u can find over there
Try DUMA, I have used it before, it's cross-platform and the latest release is recent.
Purify is a memory profiler.
You can try DebugDiag provided by windows.It can give you memory dumps and at various points and you can then check for memory leaks.
Windbg is also good.