This is an archive of the discontinued LLVM Phabricator instance.

Preliminary NetBSD support
ClosedPublic

Authored by krytarowski on Oct 1 2015, 3:28 AM.

Details

Summary

This adds platform code without the cmake/gmake glue to the existing infrastructure.

The missing and incompatibility ptrace(2) bits (existing in FreeBSD) are under active research and development and will be submitted once verified to work.

This code was tested to build and run on NetBSD-current/amd64.

Proper build scripts will be integrated separately as a new commit.

Diff Detail

Repository
rL LLVM

Event Timeline

krytarowski updated this revision to Diff 36211.Oct 1 2015, 3:28 AM
krytarowski retitled this revision from to Preliminary NetBSD support.
krytarowski updated this object.
krytarowski added a reviewer: joerg.
krytarowski set the repository for this revision to rL LLVM.
krytarowski added a subscriber: lldb-commits.
labath added inline comments.
source/Plugins/Platform/NetBSD/PlatformNetBSD.cpp
2

This platform code looks like it was copy-pasted from PlatformFreeBSD. Do you anticipate making significant changes here?

If not, it might be a good idea to share this code with FreeBSD in some way (in fact there is a comment here to make this share code with PlatformPOSIX). @emaste, what do you think about this?

krytarowski added a comment.EditedOct 1 2015, 3:58 AM

Primary reason to skip for now build scripts is that this patch takes long to be landed.

http://reviews.llvm.org/D12994

I don't want to submit a diff to patched sources...

krytarowski added inline comments.Oct 1 2015, 4:01 AM
source/Plugins/Platform/NetBSD/PlatformNetBSD.cpp
2

Yes... however I have bad experiences (mostly in Gnome) when we drag common code for rotted platforms like BSD4.4, BSD/OS and such in a single source tree paralyzing sane platform support.

labath added inline comments.Oct 1 2015, 6:17 AM
source/Plugins/Platform/NetBSD/PlatformNetBSD.cpp
2

So which one do you expect to rot first ?

Joke aside, I agree that this could be an issue, but I think if we put some thought into the design, we can limit the possible downsides of this approach. The other alternative, where we copy everything is not ideal either: we have had cases in the past, where we made a change in linux code, and then we needed to apply the exact same change in the freebsd version. So there is definitely some tradeoff to consider here...

In any case, I'm not trying to stop your changes because of this, but I think it's good to open this discussion in the early stages of the implementation... I don't know if you're aware but there are plans to move freebsd to the client-server model to follow linux, so if you make copies of the code, you may find out later that you may need to duplicate that work as well.

krytarowski added inline comments.Oct 1 2015, 6:47 AM
source/Plugins/Platform/NetBSD/PlatformNetBSD.cpp
2

I'm strongly for this to design and put common BSD code (for modern BSDs) into single library or module, limiting Free/Net specific pieces to their appropriate modules.

My requirement is to name the common parts as BSD, not FreeBSD. NetBSD isn't a variation of FreeBSD (neither e.g. Bitrig, which may come next -- there is already an active interest).

I was thinking how to do it, with virtual functions, inheritance, #ifdef magic... To make it clear, I don't use nor have FreeBSD to lonely design/redesign neither touch its platform support, therefor I request for active cooperation from the FreeBSD side.

labath added inline comments.Oct 1 2015, 7:34 AM
source/Plugins/Platform/NetBSD/PlatformNetBSD.cpp
2

I'm strongly for this to design and put common BSD code (for modern BSDs) into single library or module, limiting Free/Net specific pieces to their appropriate modules.

My requirement is to name the common parts as BSD, not FreeBSD. NetBSD isn't a variation of FreeBSD (neither e.g. Bitrig, which may come next -- there is already an active interest).

Sounds reasonable to me.

I was thinking how to do it, with virtual functions, inheritance, #ifdef magic...

LLDB is a cross-platform tool, we can already remotely debug linux from windows and mac machines, etc. It would be great if this would eventually work for BSD platforms as well. For this, we need both freebsd and netbsd code in a single client binary, so #ifdefs are ruled out (at least in client code). But I think inheritance is perfect for this particular case of PlatformNetBSD -- just move the code to PlatformBSD and have Free/NetBSD inherit from that.

To make it clear, I don't use nor have FreeBSD to lonely design/redesign neither touch its platform support, therefor I request for active cooperation from the FreeBSD side.

Let's see what FreeBSD has to say to this. :)

krytarowski added inline comments.Oct 1 2015, 8:34 AM
source/Plugins/Platform/NetBSD/PlatformNetBSD.cpp
2

LLDB is a cross-platform tool, we can already remotely debug linux from windows and mac machines, etc. It would be great if this would eventually work for BSD platforms as well.

Sounds great!

Let's see what FreeBSD has to say to this. :)

I opened the offer from my site. The code is already there. I'm waiting for the feedback.

emaste added inline comments.Oct 2 2015, 1:02 AM
source/Plugins/Platform/NetBSD/PlatformNetBSD.cpp
2

Joke aside, I agree that this could be an issue, but I think if we put some thought into the design, we can limit the possible downsides of this approach. The other alternative, where we copy everything is not ideal either: we have had cases in the past, where we made a change in linux code, and then we needed to apply the exact same change in the freebsd version. So there is definitely some tradeoff to consider here...

Yes - the sharing between Linux and FreeBSD was previously a bit of a mess: some Linux functionality existed in base classes, and some derived classes had nearly identical copy pasta.

I don't know if you're aware but there are plans to move freebsd to the client-server model to follow linux, so if you make copies of the code, you may find out later that you may need to duplicate that work as well.

Indeed. Following the current FreeBSD model of in-processes debugging (ProcessMonitor and the ptrace interface) is likely to result in a lot of wasted effort and I wouldn't recommend that part.

I was thinking how to do it, with virtual functions, inheritance, #ifdef magic... To make it clear, I don't use nor have FreeBSD to lonely design/redesign neither touch its platform support, therefor I request for active cooperation from the FreeBSD side.

A similar same question applied to the previous Linux/FreeBSD sharing, but we did not end up with a usable change -- but the Linux/FreeBSD differences are much more significant. @labath's suggestion of creating PlatformBSD and having PlatformFreeBSd and PlatformNetBSD derive from that makes sense to me.

brucem added a subscriber: brucem.Oct 9 2015, 12:47 AM

Unless someone else (@emaste?) objects, I think this looks fine to land and iterate on trunk as discussed in the mailing list thread. Just one minor comment based on cleanups that are on-going on trunk now.

source/Plugins/Platform/NetBSD/PlatformNetBSD.h
51

Might as well change this to ~PlatformNetBSD () override = default; I think.

tfiala added a subscriber: tfiala.Oct 9 2015, 7:53 PM
tfiala added a comment.Oct 9 2015, 7:56 PM

Unless someone else (@emaste?) objects, I think this looks fine to land and iterate on trunk as discussed in the mailing list thread. Just one minor comment based on cleanups that are on-going on trunk now.

Sounds reasonable.

My plan is to land this in about 16 hours unless I hear otherwise. (@labath, @tfiala, @emaste)

I would like to see these platforms merged, but I don't think that is up to me. Feel free to go ahead.

OK by me. I'd also like to see less duplication, but have no objection to this as it is now.

This revision was automatically updated to reflect the committed changes.