[lldb-dev] lldb patches for OpenBSD

[Greg Clayton]

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.

Greg Clayton

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
> http://marc.info/?l=openbsd-tech&m=130085319818542&w=2
> 
> lstat() would be good replacement. As it is defined in Open + Free BSD
> and Linux.
> 
> http://www.freebsd.org/cgi/man.cgi?query=lstat&sektion=2&apropos=0&manpath=FreeBSD+8.2-RELEASE
> http://www.openbsd.org/cgi-bin/man.cgi?query=lstat&sektion=2
> http://www.linux.com/learn/docs/man/3566-lstat2
> 
>>> 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.
> 
> http://www.cmake.org/Wiki/CMake_FAQ#What_is_CMake.3F
> 
> Thanks
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev