[lldb-dev] Native windows debugging support

[Zachary Turner]

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

>
> > On Jul 2, 2014, at 3:51 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > I'm not sure why I didn't get the original email from Greg here (?)  I'm
> only seeing this copied in Todd's response.
> >
> > In any case, Windows' concept of a user id and group id is a Security
> Identifier, as Todd mentioned (usually called a SID).  Generally though I
> don't think it's necessary to pass around the SID, because the target can
> figure out the SID given a username.
>
> So sounds like a username could be used for both windows and unix then for
> now?
> >
> > Still, it feels a little awkward having a single class store everything
> that might be needed for any platform.  Normally I'd expect to use
> polymorphic types in this scenario.  A NativeProcessLinux, for example,
> could freely cast a UserId to a PosixUserId, and a NativeWindowsProcess
> could cast a UserId to a WindowsUserId.
>
> The other option is to remove any --uid options and change them to "--user
> <string>" and the UserID classes for each platform that are polymorphic
> know how to translate a user entered string into a valid user name for that
> platform. So unix could accept:
>
> --user 123
>
> or
>
> --user gclayton
>
> But windows would only accept valid strings that represent a Security
> Identifier or a string based user name?
>
> >
> > There's also the issue of command options, as I mentioned in the
> response to Jim.  Basically, "platform process list" doesn't even need a -U
> option on Windows.  Or maybe even a stronger statement, it shouldn't have a
> -U option.  It's easy to come up with scenarios where platforms differ
> significantly enough that the same set of options don't even make sense, or
> where a certain platform provides sets of functionality not available on
> other platforms.  For those cases, it would be nice for the debugger
> commands to be tailored to that specific platform.
> >
> > So maybe my first task should be to work on the command options system a
> little bit to enable this type of abstraction.  Thoughts?
>
> If we abstract the UserID correctly we should be able to make sure they
> can construct themselves from a string + platform object correctly and
> avoid having to do any fancy options that appear/disappear based on which
> platform.
>
> Comments?
>
> Greg
>

platform process list has a number of distinct options though.  There's
uid, gid, euid, and egid.  All of that can be squashed into one string on
Windows, and as such only needs one command line option (perhaps -U, for
user)

But taking a step back, let's think about other things that are unrelated
to processes.  Windows has something called SEH, or Structured Exception
Handling.  It's kind of like C++ exceptions, where the OS itself can raise
exceptions for anything from divide by zeros, to access violations, and
other stuff.  So down the line, a useful feature for a Windows debugger
might be to allow it to trap various SEH exceptions based on the code.
 This would probably necessitate an entirely new command.

There's lots of other examples too.  A few examples:

* Windows has "jobs" and other platforms have "cgroups".  They're similar
but the semantics differ in a number of significant ways.  Controlling
these would require a slightly different command set.

* Windows supports the concept of a symbol server, a way to automatically
download and cache symbols.  No analogue on other platforms from what I
understand.

* Windows has no concept of signals, so any signal debugging functionality
would need to be disabled for a windows target.

There's probably a lot of other examples.  But I guess the point is that I
wonder whether trying to smash everything into the same interface is the
best solution.  We might need a deeper generalization.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140702/92aa4581/attachment.html>