[lldb-dev] Native windows debugging support

[Zachary Turner]

So using the UID and GID example, these concepts are not relevant for any
windows target.  However, knowledge of them is actually embedded into the
command options.  For example, you can write "platform process list -U
<uid>".  Running "platform process -U" would therefore not make sense on a
Windows host with no target, or on a non-Windows host remote-debugging a
Windows target.

Are there any examples of commands which accept different command options
depending on the target platform?  If not, are there any objections to me
adding this kind of functionality?


On Wed, Jul 2, 2014 at 3:26 PM, <jingham at apple.com> wrote:

> The way to think about this distinction is to ask yourself whether you
> would need this feature to do remote debugging from one OS to a different
> OS.  In principle, lldb should be able to cross-debug from any OS to any
> other.
>
> In this case, the way users & groups is represented is a feature of a
> process controlled by the debugger.  So the knowledge of how that works
> can't live in Host, it has to live in Target.  Note also that while Host
> code is only required to build on the platform that you are running lldb
> on, features of a process have to build on all architectures, again to
> support cross debugging.
>
> Jim
>
>
> > 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?
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140702/ccf38747/attachment.html>