Hello Harald, I had a look at your remote debugging patch and unfortunately, I have some bigger problems with it. There are basically three major issues which need to be resolved before I can integrate this into the main debugger release.
I.) Libbfd I don't like modifying the libbfd which is shipped with the debugger very much. This makes it very complicated to upgrade the bfd to a newer version in future. I've already been asked about upgrading libbfd because this may become necessary if we add ppc support. Because of that, it's important to keep the bfd changes to an absolute minimum. It should also be easy for other people (not just me) to replace the bfd, for instance if someone wants to implement support for a new architecture. One solution for this is probably adding wrappers for each of the functions into backend/arch/bfdglue.c and do the changes there. II.) The if conditionals I'm not very happy about the fact that you basically put all of backend/server/*.c inside `if' conditionals. Most of these functions are already invoked via the `InferiorVTable', so I'd prefer if we could put all the remote debugging functions into a separate file and then simply replace the vtable when remote debugging. If you need to invoke any methods which aren't in that vtable, we can simply add them. III.) Using arch-specific code in x86-linux-ptrace.c You can't use any architecture specific code in x86-linux-ptrace.c, like accessing fields inside the `INFERIOR_REGS_TYPE'. This file is shared between i386 and x86_64, so `regs->ebx' won't even compile on the x86_64. These are the major issues, there are also a few minor cosmetic ones: * Please don't use a global variable `remove_debugging_flag', put it inside the `ServerHande' instead. * Please don't copy the private struct `InferiorHandle' from one .c file into another; we can either put it into a header file or add public accessor functions. * Do we really need to add the breakpoint code to thread-db.c ? I would really like to integrate this into the main debugger, but please understand that I also need to ensure long-term maintainability and code cleanness. Martin -- Martin Baulig - [EMAIL PROTECTED] Novell GmbH, Düsseldorf GF: Volker Smid, Djamel Souici; HRB 21108 (AG Düsseldorf) _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
