<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 2, 2014 at 4:24 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
> On Jul 2, 2014, at 3:51 PM, Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> 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.<br>

<br>
</div>So sounds like a username could be used for both windows and unix then for now?<br>
<div class="">><br>
> 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.<br>

<br>
</div>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:<br>

<br>
--user 123<br>
<br>
or<br>
<br>
--user gclayton<br>
<br>
But windows would only accept valid strings that represent a Security Identifier or a string based user name?<br>
<div class=""><br>
><br>
> 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.<br>

><br>
> So maybe my first task should be to work on the command options system a little bit to enable this type of abstraction.  Thoughts?<br>
<br>
</div>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.<br>

<br>
Comments?<br>
<span class="HOEnZb"><font color="#888888"><br>
Greg<br></font></span></blockquote><div><br></div><div>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)</div>
<div><br></div><div>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.  </div>
<div><br></div><div>There's lots of other examples too.  A few examples:</div><div><br></div><div>* 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.  </div>
<div><br></div><div>* 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.</div><div><br></div><div>* Windows has no concept of signals, so any signal debugging functionality would need to be disabled for a windows target.</div>
<div><br></div><div>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.</div>
</div><br></div></div>