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

[Zachary Turner]

I think that for the purposes that I wrote HostInfo to handle, very simple
methods that answer simple queries about the host os, the virtual methods
would not be needed.  For example, what's the username of the currently
logged in user?  What's the page size?  Get the value of an environment
variable.  If something is more complicated than that, it probably belongs
somewhere else.  Do you have an example in mind that you think is a natural
fit for HostInfo, but would require calling virtual methods?

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

> >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.
>
> Right - but when we want to nuke #ifdefs, we really do need the virtual
> methods.  Which I think is all for the best.  But needs the virtual methods
> to share large bits of code and only deviate in little places.
>
> Is there any big reason not to just go to a singleton instance here?
>
> On Fri, Sep 26, 2014 at 1:30 PM, Zachary Turner <zturner at google.com>
> wrote:
>
>> 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
>>>
>>
>>
>
>
> --
> 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/c6c30ca2/attachment.html>