<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jun 9, 2010, at 10:34 PM, Eli Friedman wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Attached is my current diff to the LLDB tree to allow a mostly<br>complete build on Linux (not including the Makefiles). I'm going<br>through all the changes in my tree to let other people possibly<br>comment, and also to simply keep it organized for myself:<br><br>source/Expression/ClangExpression.cpp:<br>Hack around API change in trunk clang<br></div></blockquote><div><br></div>I can update our stuff to top of tree LLVM/Clang tomorrow to get rid of this dependency.</div><div><br></div><div><blockquote type="cite"><div>source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:<br>Linux doesn't have a header for CPU_TYPE_*. (Extend/switch to<br>llvm/Support/MachO.h or llvm/ADT/Triple.h?)<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><div><br></div>We probably need to duplicate some of the CPU_TYPE and CPU_SUBTYPE definitions so we don't require the header file. If llvm does have these defines we should start t include them from there.</div><div><br></div><div>The CPU type is much more important on the Mac due to us having 32 and 64 bit binaries that run on the same system. </div><div><br></div><div>These values get used in lldb_private::ArchSpec.</div><div><br></div><div>Currently lldb_private::ArchSpec contains the following members:</div><div><br></div><div><div>class ArchSpec {</div><div>...</div><div>protected:</div></div><div> uint32_t m_cpu; ///< The cpu type of the architecture<br> uint32_t m_sub; ///< The cpu subtype of the architecture<br>};</div><div><br></div><div>This is currently tailored for MachO, but it should be made more generic.</div><div><br></div><div>ArchSpec should be modified to take an arch type enum as well:</div><div><br></div><div>// This would go in lldb-enumerations.h</div><div>typedef enum ArchitectureType<br>{<br><span class="Apple-tab-span" style="white-space:pre"> </span>eArchTypeMachO,<br><span class="Apple-tab-span" style="white-space:pre"> </span>eArchTypeELF<br>};<br><br></div><div>class ArchSpec {</div><div>...</div><div>protected:</div><div> ArchitectureType m_type; ///< The architecture type</div><div> uint32_t m_cpu; ///< The cpu type of the architecture (cputype for macho, e_machine for ELF)<br> uint32_t m_sub; ///< The cpu subtype of the architecture (cpu_subtype for macho, anything for ELF??)<br>};</div><div><br>We would need to modify the ArchSpec class to deal with the new m_type field and do the right thing when printing.</div><div><br></div><div><blockquote type="cite"><div>source/Plugins/Disassembler/llvm/DisassemblerLLVM.cpp:<br>Linux doesn't have a header for CPU_TYPE_*. (Extend/switch to<br>llvm/Support/MachO.h or llvm/ADT/Triple.h?)<br></div></blockquote><div><br></div>See above ArchSpec comment.</div><div><br><blockquote type="cite"><div><br>source/Interpreter/ScriptInterpreterPython.cpp:<br>My build doesn't define init_lldb anywhere; I have no idea where the<br>definition is supposed to be.<br><br></div></blockquote>This comes from the file cpp file that is generated by swig when run on the ABI sources.</div><div><br></div><div>This is done by a shell script build phaes in the Xcode project that essentially does a:</div><div><br></div><div>cd scripts</div><div>sh ./build-swig-wrapper-classes.sh lldb.swig ../source/LLDBWrapPython.cpp</div><div><br></div><div>The init_lldb ends up being in the LLDBWrapPython.cpp</div><div><br></div><div><br></div><div><blockquote type="cite"><div>source/Symbol/Symtab.cpp:<br>qsort_r isn't quite portable (uses different argument order on Linux<br>and *BSD). Needs ifdeffery or switch to std::sort.<br></div></blockquote><div><br></div>std::sort bloats up to be quite large in code size and doesn't perform as well on MacOSX. Feel free to test and use something appropriate on linux if #ifdeffery</div><div><br><blockquote type="cite"><div>source/Symbol/ClangASTContext.cpp:<br>Update for API change in trunk clang; add missing include; fix include path<br></div></blockquote><div><br></div>I can update to top of tree llvm soon.</div><div><br></div><div><blockquote type="cite"><div>source/Core/Error.cpp:<br>Linux doesn't have kern_return_t or mach_error_string. Also, missing includes.<br></div></blockquote><div><br></div>#ifdef out should be fine for anything that doesn't make sense in these files for linux. Any BSD based system might support this. </div><div><br><blockquote type="cite"><div>source/Core/DataExtractor.cpp:<br>Linux doesn't have _OSReadInt* or OSReadSwapInt*; replacements are stubs.<br></div></blockquote><div><br></div>Linux must have some sort of ultra efficient byte swapping macros, no? If so, plug then in with #ifdefs. We should probably add byte swapping macros to lldb_private::Host as static inline functions if possible.</div><div><br><blockquote type="cite"><div>source/Core/ModuleList.cpp:<br>TODO port ./source/Host/macosx/Symbols.cpp to Linux<br><br>source/Core/Log.cpp:<br>Linux doesn't have mach_thread_self()<br></div></blockquote><div><br></div>We already have this abstracted in the host layer, switch to using static Host::GetCurrentThreadID (); <br><blockquote type="cite"><div><br>source/Core/ArchSpec.cpp:<br>Linux doesn't have a header for CPU_TYPE_*. (Extend/switch to<br>llvm/Support/MachO.h or llvm/ADT/Triple.h?)<br></div></blockquote><div><br></div>llvm/support/macho.h and augment ArchSpec as stated above..</div><div><br><blockquote type="cite"><div>source/Core/FileSpec.cpp:<br>st_mtimespec is BSD-only, st_mtim is Linux only AFAIK; maybe switch to<br>llvm/System/Path.h?<br></div></blockquote><div><br></div><div>As long as we don't run into any RTTI issues, sure thing.</div><br><blockquote type="cite"><div>source/Core/Args.cpp:<br>optreset is BSD-only; needs ifdeffery or switching away from getopt()<br></div></blockquote><div><br></div>As long as what ever gets used works on both systems, I don't mind what happens here.<br><blockquote type="cite"><div><br>source/API/SBTarget.cpp:<br>Symptom of large change; I moved all the files from source/Commands to<br>source/Interpreter to fix a circular dependency.<br></div></blockquote><div><br></div>Which circular dependency?</div><div><br><blockquote type="cite"><div><br>source/Host/linux/TimeValue.cpp:<br>Mostly copied from source/Host/macosx; why not just use llvm/System/TimeValue.h?<br></div></blockquote><div><br></div>As long as there are no RTTI issues, that would work.</div><div><br></div><div><blockquote type="cite"><div>source/Host/linux/Host.cpp:<br>Nasty hacked port to get rid of OSX-specific stuff.</div></blockquote><div><br></div>Hopefully we can contain all Host specific things into these Host.cpp files. Was anything particularily hard? Anything not make sense?</div><div><br><blockquote type="cite"><div>(source/Host/linux/Mutex.cpp and source/Host/linux/Condition.cpp are<br>copied unmodified; it'd be nice to contribute the condition variable<br>to core LLVM and get rid of the LLDB versions)<br></div></blockquote><div><br></div>Works for me as long as there are no RTTI issues.</div><div><br></div><div><blockquote type="cite"><div>source/lldb.cpp:<br>The include paths here are a complete mess; perhaps the init functions<br>should be declared in a common lldb/Plugins/PluginInit.h<br></div></blockquote><div><br></div>The init routines are currently taking place of actually compiling separate plug-ins and loading them dynamically. Usually all plug-ins would be detected by searching a common set of machine and user paths for lldb plug-ins to load. We were initially doing this with objective C and Bundles (thus why some of the files had a ".mm" extension, they used to have objective C plug-in loading code in there). Once we finalized on the fact we were going to integrate with LLVM, we started slowly moving away from ObjC stuff and slowly got rid of all that stuff. </div><div><br></div><div>Plug-ins in LLDB reverse the roles where the plug-ins register themselves with LLDB instead of LLDB asking each plug-in what it supports. Some of the Initialize()/Terminate() calls in lldb.cpp are parts of the LLDB core initializing themselves, and others are the PLUGIN::Initialize() and PLUGIN::Terminate() functions being manually called to avoid doing plug-in loading dynamically for the time being.</div><div><br></div><div>So right now these Initialize()/Terminate() calls need to happen, tough it would be a good idea to segragate the plug-in implementations from the Core Initialize()/Terminate() routines.</div><div><br></div><div><blockquote type="cite"><div><br>tools/driver/Driver.cpp:<br>optreset is BSD-only; needs ifdeffery or switching away from getopt()<br><br>include/lldb/Core/Error.h:<br>kern_return_t is OSX-only.<br></div></blockquote><div><br></div>#ifdef out for other non-BSD systems.</div><div><br><blockquote type="cite"><div>include/lldb/lldb-types.h:<br>Remove non-portable includes (needs testing on a Mac).<br></div></blockquote><div><br></div><br><blockquote type="cite"><div><br>-Eli<br><span><lldbdiff.txt></span>_______________________________________________<br>lldb-dev mailing list<br><a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev<br></div></blockquote></div><br></body></html>