[Lldb-commits] [PATCH] Make llgs build on Android. No functionality change.

Reid Kleckner rnk at google.com
Fri Sep 26 13:27:32 PDT 2014


On Fri, Sep 26, 2014 at 1:17 PM, Todd Fiala <tfiala at google.com> wrote:

> Hey Zachary,
>
> I just started looking at the HostInfo* classes.  I'm a little confused -
> we are going to want to have Android behavior differ in just a tiny little
> way from Linux (and POSIX).  So we're going to want to break out some
> implementation details into some virtual methods that are possibly no-op or
> different-op on the *largely same* code for POSIX/Linux.  Yet all the calls
> in these classes are static.
>
> Why isn't this just a class instance hierarchy?  We're going to want it to
> be more like that so we can use typical C++ class design patterns like
> using virtual methods and the like.
>
> Or did you have some other paradigm in mind for nearly-similar classes
> that want to share the bulk of the code in these classes?
>

You can probably inherit from HostLinux and override any static methods you
need to, as long as you add HostAndroid to the ifdefs in HostInfo.h:

#if defined(_WIN32)
#include "lldb/Host/windows/HostInfoWindows.h"
#define HOST_INFO_TYPE HostInfoWindows
#elif defined(__linux__)
#include "lldb/Host/linux/HostInfoLinux.h"
#define HOST_INFO_TYPE HostInfoLinux
#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
#include "lldb/Host/freebsd/HostInfoFreeBSD.h"
#define HOST_INFO_TYPE HostInfoFreeBSD
#elif defined(__APPLE__)
#include "lldb/Host/macosx/HostInfoMacOSX.h"
#define HOST_INFO_TYPE HostInfoMacOSX
#else
#include "lldb/Host/posix/HostInfoPosix.h"
#define HOST_INFO_TYPE HostInfoPosix
#endif

On Fri, Sep 26, 2014 at 1:09 PM, Todd Fiala <tfiala at google.com> wrote:
>
>> >>! In D5495#27, @zturner wrote:
>> > I'm not seeing the changes to HostInfoPosix and HostThreadPosix that I
>> > suggested.  Are those still coming in a followup?
>>
>> With Android, it's *mostly* Linux (at the kernel level) except we have a
>> whole slew of different runtime libraries that differ.  So, for much of the
>> behavior, it will be like Linux/POSIX, but with certain libc calls and
>> whatnot that just don't exist.  Ideally we minimize how much we differ and
>> only when needed.
>>
>> Tong, can you take a look at that?  If we need a Linux-derived Android
>> variant of these classes, this might be a good time to look at those.
>> Thanks.
>>
>> > (paraphrased) how do you launch on Android, then?
>>
>> In general you don't.  The Android zygote takes care of launching for
>> userland, and debuggers usually run attach-only.
>>
>> That's just a half-truth, though.  We do have low-level, internal
>> capabilities for launching,  but since that is not a supported path for
>> developers, they are not exposed in a way we can access with POSIX-like
>> calls.  The launch code might end up only showing up in an AOSP environment
>> but, in any event, the attach path is the crucial one for Android right now.
>>
>> http://reviews.llvm.org/D5495
>>
>>
>>
>
>
> --
> Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
>
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20140926/39d80055/attachment.html>


More information about the lldb-commits mailing list