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

[Todd Fiala]

If there is concern over calling a GetHostInfoInstance() or some kind of
singleton caller, we can always wrap that in static calls that do it for
us.  But I'd much prefer here to have an instance with a vtable.

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

> I think some of the changes you wanted to see Tong make (which I think are
> fine to change) are what Tong's looking at now, which need to deviate some
> POSIX code in very minor ways.
>
> Tong - can you call out the code for us?
>
> Thanks,
> Todd
>
> On Fri, Sep 26, 2014 at 1:34 PM, Zachary Turner <zturner at google.com>
> wrote:
>
>> 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
>>>
>>
>>
>
>
> --
> 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/8a6edf10/attachment.html>