[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference clt::fuse

Title:DEC FUSE - UNIX SDE
Notice:See note #4 for kit locations
Moderator:TLE::TALCOTT
Created:Tue Oct 30 1990
Last Modified:Fri May 23 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1276
Total number of notes:4364

1264.0. "Support for GNU Compilers" by ZPOVC::COLINTONG () Thu Mar 13 1997 07:35

    Hi,
    
    This questions had been asked two years ago with no definite answer. I
    hope we will have more positive news this time.
    
    We are in the final stage of two TurboLaser opportuntity competing with
    SGI. The customer is using GNU C and C++ in existing SGI environment
    and would like to know if DEC FUSE supports the above compilers. The
    tools of particular interest are:
    
    	* Builder
    	* Debugger
    	* Performance Analyzer
    	* Heap Analyzer
    
    Not necessary to be an offical reply and any sharing of expereience
    will be appreciated.
    
    Thanks 
    
    Colin Tong
T.RTitleUserPersonal
Name
DateLines
1264.1the debugger answerTLE::ROLFHAMREThu Mar 13 1997 14:1829
        <<< 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
1264.2gcc && FUSETLE::JRICHARDFri Mar 14 1997 15:5114
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.
1264.3TLE::FINLAYSONMon Mar 17 1997 11:3416
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