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

Zachary Turner zturner at google.com
Fri Sep 26 13:46:24 PDT 2014


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


More information about the lldb-commits mailing list