[lldb-dev] remote debugging from another platform
gclayton at apple.com
Wed Sep 5 11:11:00 PDT 2012
Carlo: I created a branch for the windows work to happen in:
svn co http://llvm.org/svn/llvm-project/lldb/branches/windows
You can check in anything you want into here. We currently lock down the build to a specific version of llvm/clang which is mentioned in the "$llvm_revision" and "$clang_revision" variable in the "lldb/scripts/build-llvm.pl" script. It is currently set to: r152265 for both. You have patches that need to be applied to the sources then you should include those patches in "lldb/scripts/llvm.amalgamated.diff" and the "lldb/scripts/clang.amalgamated.diff". These will then be applied to the llvm/clang builds before we start building LLDB.
> I continued with this to see how far I can get:
> With a slight tweak in llvm (to get back the original string from a regex class), and a few tweaks over lldb itself the compile progress gets pretty far (doesn't compile as is with the patch yet, some of the errors I get on Windows stop me from seeing all errors)
> SymbolVendorMacOSX.cpp has a dependency on libxml & AvailabilityMacros.h
Feel free to #ifdef around this for now with an appropriate "TODO: cross build issues" comment
> process.cpp has a lot of platform dependent stuff
> platform.cpp depends on getops.h, not sure if this works on windows too but it's not standard
The includes for Platform.cpp have:
It is probably in one of these .h files that tries to #include the "getops.h", you will need to locate that file and work around it somehow.
> replaced the regex with llvms' regex (Requiers a tiny patch in llvm itself)
Sounds good, please add the appropriate patch to the "lldb/scripts/llvm.amalgamated.diff" or "lldb/scripts/clang.amalgamated.diff" as needed.
> GDBRemoteCommunicationServer.cpp has a lot of platform dependent stuff
The #include files are all from LLDB sources, again, check which #include inside these files needs to be fixed.
> objectcontainerbsdarchive.cpp depends on ar.h (which is missing)
See if LLVM has the defines from ar.h abstracted into one of their header files. If they don't we will need to add them. Let me know what is missing (comment out the #include <ar.h> and let me know what errors you run into. Typically, LLVM and Clang usually have these defined with different names inside an appropriate namespace. We need to move away from depending on system header files.
> For emulationstatearm.h:
> Error 4241 error C2380: type(s) preceding 'sd_regs' (constructor with return type, or illegal redefinition of current class-name?) lldb\source\plugins\instruction\arm\emulationstatearm.h 90 1 lldb
> which causes like 100 follow-up errors.
> DisassemblerLLVMC.cpp depends on regex.h (c style); probably can be ported to llvm regex or llvm's internal_regex stuff, which seem to match in the apis.
Yes, no one should be using "regex.h" directly. What we really need to do is to have our lldb_private::RegularExpression class use the LLVM implementation and remove all #includes to "regex.h" so we abstract all regular expression stuff into one place.
> Abstracting everything in a windows/ specific folder does not look like it's very practical, __attribute__ isn't even supported in VC++ and used all over the place.
For LLDB we need to make sure all __attribute__ things are abstracted into preprocess #define macros. It looks like this is primarily used for PRINTF string errors/warnings like
Error (const char *fmt, ...) __attribute__ ((format (printf, 2, 3)));
We can add a macro to "lldb/include/lldb/lldb-defines.h" that checks for windows (using a correct preprocessor test, not the one I use below):
#define LLDB_PRINTF_FORMAT_ATTRIBUTE(n,m) __attribute__ ((format (printf,n,m)))
Then the code above would become:
Error (const char *fmt, ...) LLDB_PRINTF_FORMAT_ATTRIBUTE(2,3);
> That said, I think I can get this all working so at the very least remote debugging from windows to other platforms works, maybe with some help on the issues above.
Sounds good, again, checkout the new windows branch:
and make all your changes on that branch. When we have something we are happy with, we will merge this back into mainline.
More information about the lldb-dev