| <<< TURRIS::DISK$NOTES_PACK:[NOTES$LIBRARY]DECLADEBUG.NOTE;1 >>>
-< Digital Ladebug debugger >-
================================================================================
Note 882.1 GNU Compilers 1 of 2
QUARRY::petert "rigidly defined areas of doubt and " 10 lines 13-MAR-1997 11:06
--------------------------------------------------------------------------------
> Can LaDebug support GNU C and C++ compilers.
That depends entirely on what type of symbol table information they
put out. Since gdb can debug our C code, I wouldn't be surprised if
gcc and g++ (that's the right one, isn't it?) produce output on the
Alpha that our debuggers can handle. I've even got a vague notion
this is true, but I don't have hard data for you.
PeterT
================================================================================
Note 882.2 GNU Compilers 2 of 2
CXXC::MJHANS "Matthew Hanselman, DEC C/C++" 8 lines 13-MAR-1997 11:12
-< Maybe yes for C, no for C++ >-
--------------------------------------------------------------------------------
Completely unofficial -- In short, probably yes for C, no for C++.
I've successfully debugged GNU C code with ladebug, but had ladebug get
hopelessly confused with GNU C++. It may be possible to have ladebug get
hopelessly confused with GNU C as well, but I haven't gone out of my to
find out one way or the other.
- Matt
|
|
This is all unofficial, based on my use of gcc 2.7.2:
I've had pretty good luck using gcc with FUSE. The warning/error
messages show up in the builder, and you can get to the line number
via clicking on the warning/error line.
The Heap Analyzer/Profiler also seem to work OK with gcc. The data
even displays to the Program Visualizer. But it's best to
ask the folks that develop atom (third) how well it will really work
with gcc.
Also, the static analysis tools use cxx to scan C++ code. So if
cxx isn't able to compile the code, these tools may give errors.
|
|
I checked with the folks that do the base profiling tools (prof, gprof, hiprof,
pixie, third). The short answer is that they haven't been testing against the
GNU compilers, but in general things should work.
For a somewhat longer answer, prof & gprof should work as long as the symbol
tables are reasonably compatible, and either gcc/g++ use the libprof1.a that
comes with Digital UNIX to implement support for -p & -pg, or that they generate
mon.out & gmon.out files in the defacto standard format.
The various Atom tools (pixie, hiprof, third) should work OK as long as the
compilers don't generate any unexpected instruction sequences. Also,
multi-threaded applications must use DECthreads for the Atom tools to work, but
this is a constraint on the Digital compilers too.
Mark Finlayson
|