[lldb-dev] lldb patches for OpenBSD

[Stephen Wilson]

On Thu, Mar 31, 2011 at 10:47:35PM -0500, Amit Kulkarni wrote:
> Hi,
> 
> I have several small fixes for OpenBSD, I am just compiling lldb, not
> at all meaning to run it for now. Please give feedback.
> 
> 1) C99 discourages LONG_LONG_MAX, ULONG_LONG_MAX, and relatives? Can
> this be fixed properly by complete replacement or
> you would settle for ifndef in the code? I don't know if it exists on
> Mac OSX and Linux, so can you please change appropriately? I have
> included a ugly ifndef in a DataExtractor.cpp and DNBDataRef.cpp.

AFAIK LONG_LONG_MAX is a GCC thing, and only available on linux with
certain compiler flags (-D_GNU_SOURCE for example).  I would imagine
Clang provides it too for compatibility.  I think the solution here is
to just not use it.

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.


> 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.

> 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?


> 4) return (uint64_t) (pthread_self()); is a poor hack for getting
> thread id in Host.cpp. 

Agreed.  But in this case we just have not gotten around to writing the
proper support.  For linux we should be calling gettid(2) and have that
factored out into the linux-specific side of the Host implementation.

For OpenBSD perhaps it makes sense to create a new Host subdirectory so
this stuff can get handled as appropriate for the platform?  Perhaps one
that can be shared between all {Open,Free,Net}BSD's?  I am not too sure
what would make the most sense here.


> I hope to correct that in with feedback from
> more knowledgeable people here on this board. I privately sent a email
> to an OpenBSD developer, Matt Dempsky who wrote.
> 
> > llvm/tools/lldb/source/Host/common/Host.cpp:410: error: cast from
> > 'pthread*' to 'lldb::tid_t' loses precision
> 
> "That's because tid_t is a uint32_t, but on 64-bit arches pthread_t is
> a pointer, and so it's a 64-bit value.  It would probably be better to
> change tid_t to a uint64_t.  I don't imagine that would be a
> controversial change, and it affects all 64-bit non-Apple platforms, I
> believe."

For linux we use 32-bit pids on all platforms I think.  But I have no
big worries about growing lldb::tid_t to 64-bits if a platform needs to
stuff a pointer in there.  Out of curiosity, how does OpenBSD enumerate
threads?


> 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.


-- 
steve