[Mono-list] mcs targets/definitions

[Kenneth Brubaker]

Jonathan,

Thanks for your answers! And, by the way, I was not at all dispariging the 
Mono development effort in regards to parallelism to CLR, but simply support 
for things such as registry etc. It's obvious that the Mono team is 
dilligent and will be successful. And if I develop my libraries on Mono as 
well as .NET, rest assured that I will at least post bug reports when I find 
them.

Regarding symbols in release builds, I just had to explain to one of the 
architects where I'm working that you CAN debug release builds. I recommend 
always producing debug symbols in release builds.

Kenneth Brubaker


----Original Message Follows----
From: Jonathan Pryor <jonpryor@vt.edu>
To: Kenneth Brubaker <kennethbrubaker@hotmail.com>
CC: mono-list@lists.ximian.com
Subject: Re: [Mono-list] mcs targets/definitions
Date: Tue, 09 Sep 2003 20:32:56 -0400

Attempted answers inline...

On Mon, 2003-09-08 at 23:42, Kenneth Brubaker wrote:
 > (1) Would there be any reason to have a Release and Debug builds using 
the
 > current mcs?

Not right now...

 > I don't see any optimize flags.

Exactly.  So what would a Release build add? :-)

Plus, with Debug builds it makes it easier for other developers.  (Yay
line number information in stack traces when run with "mono --debug"!)

 > There is, of course a debug
 > flag (two for some reason--why?

Why?  Compatibility with Microsoft's CSC.EXE, which has "debugging
information" (/debug) and "lots of debugging information" (/debug+), if
memory serves.  I found it confusing at the time, myself...

Mcs is option-compatible with CSC.EXE (makes it easier to write
makefiles), so that's why MCS has the multiple debug options.

"-g" is a mcs extension, for all us GCC users who expect "-g" to be
present in all compilers, and curse Microsoft for not using -g as
well... ;-)

 > ), but I always prefer to produce debug
 > symbols for my release builds. (Yes bugs CAN occur in release builds :-o 
)
 > Does the debug flag affect performance of the generated IL?

Any takers?

My partial answer is that there need not be a reason for debug
information to impact performance.  The primary reason C code has a
performance degradation with debug code is that x86 code loses a
register to store the "frame pointer," which is used to generate
accurate stack traces.  x86 is register starved as it is, so this
greatly contributes to the decline in code, assuming the code
optimizations are enabled.

.NET CIL permits much more accurate tracking of variables in code, so a
frame pointer isn't strictly needed, so it *should* be possible to get
create optimized code that also contains debug symbols and is useful for
debugging.

Whether mono actually does this, I can't say.

 > (2) Is there a macro defintion built into the MCS compiler on the order 
of,
 > say, "MONO," so that conditional compilation can occur if, on the outside
 > chance, the implementation is not perfectly alligned with the MS FCL?

Yes... and No.  Yes, mcs defines __MonoCS__ symbol... and you should
ignore it. :-)

You should ignore it because it only says that your code is being
compiled with mcs.  It doesn't say that you're running under Mono on
Linux, Mono on Windows, or under .NET.  Which amounts to making it
worthless for signaling platform-dependent code.

The solution is to create your own symbol, and #if off that.  Or, use
runtime checks.  Or, make sure that Mono *is* perfectly aligned with
.NET's FCL by filing bugzilla bugs and contributing. :-)

 > Kenneth Brubaker

  - Jon

_________________________________________________________________
Get 10MB of e-mail storage! Sign up for Hotmail Extra Storage.  
http://join.msn.com/?PAGE=features/es