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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]> 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 | [email protected] | 650-943-3180 >>>> >>> >>> >> >> >> -- >> Todd Fiala | Software Engineer | [email protected] | 650-943-3180 >> > > -- Todd Fiala | Software Engineer | [email protected] | 650-943-3180
_______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
