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

[Zachary Turner]

FWIW, there's really only 1 function that this applies to.  All of Tong's
other changes were not in HostInfo.  AFAICT the only function this applies
to is HostInfoPosix::LookupGroupName.

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

> Agreed. We'll move this off thread.
>
> Tong, for now let's just replicate the bits we need to and we'll see how
> much duplication we end up with.
>
> -Todd
>
> On Fri, Sep 26, 2014 at 1:46 PM, Zachary Turner <zturner at google.com>
> wrote:
>
>> Would it make more sense to discuss this in a separate thread on
>> lldb-dev?  Even if we end up doing that, it's outside the scope of this
>> patch.  For this patch I'd prefer the android specific stuff to go in
>> Host[Info/Thread]Linux, since that is the most-specific implementation it
>> can go in.  If we decide to make the instance change after discussing it in
>> the larger context on lldb-dev, I can go through and do it.
>>
>> On Fri, Sep 26, 2014 at 1:40 PM, Todd Fiala <tfiala at google.com> wrote:
>>
>>> 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
>>>
>>
>>
>
>
> --
> 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/61166272/attachment.html>