[lldb-dev] lldb patches for OpenBSD
gclayton at apple.com
Fri Apr 1 11:24:17 PDT 2011
I just checked in some fixes:
Committed revision 128720.
Committed revision 128721.
Does this take care of all your issues? I will respond about the thread ID one in a separate email.
On Apr 1, 2011, at 11:22 AM, Amit Kulkarni wrote:
>> I think using ULLONG_MAX and friends makes sense. For platforms that do
>> not define them we can easily provide our own in a config.h.
> OK, I will resend a diff with LLONG_MAX and ULLONG_MAX only.
>>> 2) File.cpp needs <sys/stat.h> because all the permissions like
>>> S_IRUSR, S_IWUSR, S_IROTH, S_IXOTH etc are defined there in OpenBSD
>>> and FreeBSD (both -current or head sources). I don't have any Linux
>>> sources around but Linux knowledgeable people will correct me, if its
>>> needed there, if not we can add ifndef?
>> Hmm. They are defined there on linux too -- must be getting included
>> indirectly somehow. I do not see any reason to not just include the
>> missing header directly in this case; no need to ifdef it AFAICT.
> That's great then.
>>> 3) DT_WHT won't be defined in <sys/dirent.h> on OpenBSD. In fact, it
>>> was specifically removed.
>> Interesting. We get the d_type field only when _BSD_SOURCE is defined
>> on linux. Perhaps we should just be calling lstat(2) here?
> Theo's words, I don't know why he didn't elaborate, anyway
> lstat() would be good replacement. As it is defined in Open + Free BSD
> and Linux.
>>> Also, is there any interest in convert the Makefiles into CMakeLists.txt?
>> I personally to not know CMake very well. I have used it a few times
>> but not on a substantial project by any means.
>> I do not have any flat out objections to using CMake. Eventually we
>> need a configure-like stage that I was eventually going to get around to
>> implementing but if that can be done using a new CMake build then that
>> would be fine with me (I think).
>> However, the test suite is based on makefiles and I do not have a
>> hand in that side of things. CMake would need to be a good fit in that
>> context too.
>> Also, I think we would need to discuss if CMake can generate suitable XCode
>> project files since its big advantage is the cross-platform thing. If we
>> cannot use it as a cross-platform build system then I am not too sure
>> what advantage is has over good old make.
> CMake is much better than anything to generate XCode project files,
> Windows Vistual Studio support, Unix makefiles etc. I have hand
> written some CMakeLists.txt files based on llvm/clang CMakeLists.txt
> itself, but they will need to be updated by you guys when you make the
> commits which add, delete, or rename files. If you follow and update
> the CMakeLists.txt religiously, you can get lldb to be compiled on
> almost all platforms. Of course the biggest hurdle is the support to
> be added inside lldb for BSD's, Windows etc. But with CMake you can
> just forget about adding tweaks for all OS to get it to compile. You
> can concentrate on development and CMake takes care of compilation.
> If you are committed to using CMake, I will send across the files
> after polishing it up... They aren't yet done for all the folders yet
> but a major chunk is done. I really want to see lldb on OpenBSD, now
> that gdb is inaccessible due to GPL v3.
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
More information about the lldb-dev