[Mono-list] testing mcs (specifically: compiling protected internal methods)

Duco Fijma duco@lorentz.xs4all.nl
27 Mar 2002 22:40:29 +0100

I'm currently busy with a more or less structured test of mcs.
Yesterday, I put some bug reports on pre-processing in bugzilla.

Today, I found something strange in the way protected internal methods
are compiled and/or disassembled. This might be some combination of bugs
(in mcs and monodis), so I'm not quite sure where to document this.

Consider the following example:

namespace Test {

        class Test {

                protected internal int MyProtectedInternal ()
                        return 42;


Some questions/remarks I came up with while playing with this code:

A) Compile this to a dll using both csc and mcs under Windows: when
disassembled using ildasm, the IL-code of the "MyProtectedInternal"
method in the csc-generated dll is nicely decorated with "famorassem",
while the mcs-generated version is not.

B) Compile this to a dll using mcs under Linux, subsequently trying 
to disassemble this using monodis results in an error message:

(process:5151): ** ERROR **: file util.c: line 30 (map): should not be
Trace/breakpoint trap

C) Why is it I can't do anything in Windows with a .dll or .exe
generated using mcs.exe on Linux? I expected that I could generate a
small dll out of the example code above in Linux and inspect it using
ildasm on Windows, but this fails. What obvious reason am I missing?
Even the "hello world" executable, generated on Linux, can't be used on

D) It is probably not my discovery that mcs does not check
accessibility. Is this what is meant with bug #21147 ("mcs should check
accessibility if methods, fields, etc.")? The description of this bug
seems rather specific, while this feature seems to be missing in

E) Do we have any strategy for turning small compiler test cases like
this into reusable regression tests?