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

[Zachary Turner]

It wasn't made a class instance hierarchy for the same reason that Host
wasn't a class instance to begin with.  HostInfo only contains method that
are inherently static.  You could make it an instance, but it would be
awkward, because you would have to create one for the sole purpose of
calling a method that is actually static.

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?
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20140926/fbfabe55/attachment.html>