[Mono-dev] Mono debugger on windows

[Joachim Ante]

Hi,

My company wants to fund development of the mono debugger on Windows.
This is a fully paid contracting gig and all the developed code will  
go into under the x11 license.
Martin will give you feedback during development to make sure that  
the changes are maintainable for novell after the project is complete.

Optimally we are looking for someone with the following skills:
* Intimate knowledge of the Windows debugging API
* Knowledge of the mono debugger implementation
* Experience with solving race conditions and threading issues

Not all of these skills are required, primarly you should just be  
very interested and feel confident that you can handle the project.

The port involves:

* A backend for reading PE files for the native support (reading  
symbols, addresses, etc).
This part is fairly straightforward. It's essentially just parsing PE  
files.

* Porting the ptrace layer to the Windows debugging API's
replacing the ptrace() layer in backend/server/x86-ptrace.c.

Potentially it also requires replacing various C# code like backend/ 
ThreadManager.cs to handle a different debugging model.
Some other parts of mono might also have to be adapted to the way the  
Windows debugging API works


If you are interested in this, please contact me. I am eager to move  
ahead on this very quickly.

Below I have pasted some more detailed information from an e-mail  
conversion with Martin and Miguel.

Best regards,
Joachim Ante




Hi,

I quickly talked to Miguel on the phone yesterday, so let me add a few
more details:


> Here is what the port would require:
> * A backend for reading PE files for the native support (reading
> symbols, addresses, etc).  On Linux we do this with BFD, but we plan
> on dropping it in the future and using a managed version for just
> reading ELF files.
>

Yes, that's really trivial.  A few weeks ago, I wrote a semi-working
managed elf reader on a Saturday afternoon, just to figure out how much
work would be involved.

So that's basically just a matter of reading the PE file format specs
and then write the code.


> * A new 'arch' directory to support the Windows debugging system.
> This is the area where we have no knowledge of any kind, so this
> requires someone with Windows expertise to do this.
>
> * Porting the OS bits, that should not be too hard.
>

That's actually the most difficult part of it (I'll explain it below).

First of all, we need to distinguish between porting the debugger to
another operating system and porting it to another hardware
architecture.

Porting it to a different hardware architecture is a lot of work, but
it's pretty much straightforward and just a matter of writing the code.
So from a skill level, it's a lot easier to do.

There are three parts:

* The hardware specific bits in the backend/arch/ directory, especially
   Architecture.cs, Instruction.cs and Opcodes.cs.

   This requires a little bit of knowledge about how the Mono JIT does
   things like trampolines etc., but not really that much.

   This is all managed code.

* The hardware specific bits in backend/server/{x86_64|i386}-arch.c.

   This also involves writing marshallers for method invocations,  
reading
   stack frames etc.

* A replacement for libopcode - if you guys don't like the BFD license
   of it.

   However, there is no technical requirement for this - it's only used
   to display disassembly to the user, but it's not required for  
anything
   besides that.  So we could simply disable disassembly support on a  
new
   hardware architecture.

That's basically it.

Historically, the debugger also used bfd / libopcode to get the size of
an instruction, which is required for single-stepping.  This code has
been replaced by a fully managed version about a year ago.

So today, we only need bfd to read symbols and the contents of a
section.

                                 * * *

Ok, now let's move on to porting the debugger to a different operating
system.

Porting it to a different operating system like Windows requires
replacing the ptrace() layer in backend/server/x86-ptrace.c.

Unfortunately, I have no idea how much work this would be - and to make
things worse, we won't figure it out until we actually start writing the
code.

The biggest difficulty you guys may run into are potential changes to
the way how the debugger's main loop is structured.  This basically
requires someone who understands both the ptrace() and the windows
debugging models.

You may actually need to completely replace backend/ThreadManager.cs
which a version suited for the Windows debugging model.  This also
requires some deeper understanding of mdb internals, but I'll gladly
help with this part.

On Linux, we're using two threads in the debugger's main event loop:

* The engine thread is the only thread which is allowed to access the
   target - and all target access needs to go through this thread.

   This is a stupid requirement set by the Linux kernel and there's
   nothing we can do about it on Linux.

   The engine thread receives events from both the wait thread and
   the user.

   If you want to use mdb on Windows to debug Unity, then we should
   figure out whether we also need this special thread for the Windows
   debugging API - as removing it could potentially give a significant
   performance increase.

* The wait thread is blocking on waitpid() and signals the engine
   thread when the target has stopped.

>
>
On Linux, this entire model is very complex and difficult and there are
many race conditions which may arise.

My guess is that things may be easier on Windows, assuming that the
Windows debugging API is most likely a lot less brain-dead than the
Linux one.

Because of that, you should look for someone with some expertise on
threading issues.

I hope I didn't discourage you too much with this, as it'd be really
great to get the debugger ported to Windows.

If you have any more questions, don't hesitate to ask, I'll gladly help.

Martin