[lldb-dev] Native windows debugging support

[Todd Fiala]

We'll probably end up needing to support something like this:
https://en.wikipedia.org/wiki/Security_Identifier

Most of the access control on Windows ends up revolving around those.


On Wed, Jul 2, 2014 at 3:37 PM, Greg Clayton <gclayton at apple.com> wrote:

>
> > On Jul 2, 2014, at 2:52 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > I've started experimenting with adding support to LLDB for debugging
> native Windows executables on Windows.  So windows host, windows target.
>  I've done a few little cleanup tasks here and there and fixed some
> low-hanging fruit, and I'd like to move onto something more meaty.
> >
> > I took a look at what it would take to get "platform process list" to
> work.  The first thing I notice is that all of the Process info objects
> contain the notion of a UID and GID, a concept which doesn't really exist
> on Windows.  An analagous concept exists, but it's represented completely
> differently.
> >
> > My question is: How best to abstract out this functionality?  I'm still
> not totally clear on where I'm allowed to use platform specific types /
> APIs and where it needs to be platform agnostic.  My first thought is to
> remove UID and GID from the ProcessInfo class, and replace them with a
> instance a "ProcessUserId" class, then provide a PosixProcessUserId and a
> WindowsProcessUserId, which abstracts away the differences.
> >
> > Assuming this approach is logical, where is the best place for this code
> to go?  Host or Target?
> >
> > Anything else I should be aware of?
>
> Can we just make a UserID class and GroupID class which contains both an
> integer and a string (and anything else that is required) and use that?
> What does windows have as far as UID and GID goes? Will strings suffice?
> Does it need more? As you can tell we are very unix centric right now, but
> we do want to abstract. So I would go the route of making a UserID and a
> GroupID class, everyone uses these classes and these classes need to be
> able to store everything that all of our classes require. My simple guess
> would be:
>
> class UserID {
>    std::string m_name;
>    lldb::user_id_t m_identifier;
> };
>
> Same for kind of thing for GroupID.
>
> Greg
>
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>



-- 
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-dev/attachments/20140702/5dc813dd/attachment.html>