[Mono-dev] Mono Debugger and Mono 2.4

jonas echterhoff jonas at unity3d.com
Fri May 8 06:09:23 EDT 2009


Following up on my own post here, I have managed to make mdb work with  
Unity (to some degree). It was mostly as easy as Miguel said, just  
instruct Unity to use mono the same was as if "mono --inside_mdb" had  
been called.

Reading the MONO_DEBUGGER__debugger_info struct still is a problem,  
though. I was wrong in my last post that mdb won't try to read it for  
native applications. Rather, the problem is, that since we are linking  
against mono dynamically, the debugger will first interrupt when  
loading Unity, before the linker has resolved the external dynamic  
symbols, thus it won't get the correct address for the struct.

I have worked around this for now, by making the debugger ignore the  
first stop, which works, but breaks compatibility with everything but  
Unity - so I really need some better fix. Does anybody know the OS X  
linker very well? I tried setting the DYLD_BIND_AT_LAUNCH environment  
variable, but that still seems to link the symbol too late. If nobody  
knows a more elegant solution, I'd need to change the debugger to try  
again and read the symbol table again, if the symbol is unresolved the  
first time, but if it can be fixed by some different link settings,  
i'd prefer that.

jonas

On May 5, 2009, at 5:37 PM, jonas echterhoff wrote:

> Yes. But in order to make it work, as far as i can tell, I also need
> to change the mono debugger itself. Right now, when I load a native
> application into the debugger, it won't try to find the debugger_info
> global structure, which is used to communicate with mono.
>
> My question is mostly, since there is some "support" for native
> applications in mdb at this point (well, I can start an application in
> the debugger, and interrupt and resume execution), if there is already
> some workaround for this, or a plan on how to implement it. I
> obviously don't want to do special case code for unity which will be a
> pain to drag along in the future.
>
> jonas



More information about the Mono-devel-list mailing list