We might also need the ability to create lldb specific errors and be able to 
have the windows and posix errors be converted to an internal LLDB enumeration. 
A few examples:

- bad argument
- bad/invalid file handle
- out of memory
- end of file

We don't tend to look for specific errors in many places, but sometimes we do 
check for certain things. And it might be nice to be able to do:

Error error = some_object->PlatformSpecificCall();

and then do:

if (error.IsEOF())
{
    ...
}

And the code within error would take care of the details even though it might 
be a posix or windows error...

Most of the places it is nice to just let the error string speak for itself 
(Error::AsCString(...)), but sometimes we do need to know what went wrong by 
checking for an specific error code.

Greg

> On Aug 28, 2014, at 1:00 PM, Zachary Turner <ztur...@google.com> wrote:
> 
> Indeed, relying on errno on Windows is not the correct solution for many 
> reasons.  Actually I don't think converting their error numbers to POSIX 
> error values is a good solution either.  I'm of the philosophy that if you're 
> on Windows you should be writing windows code.  Recently I added 
> eErrorTypeWin32 as a category to lldb::Error.  When you create an error with 
> that category, you can directly pass it the result of GetLastError().  
> Unfortunately, that's literally all I did.  Planned for the future would be 
> an implementation of Success() and Failure() that returns the right thing 
> when type == eErrorTypeWin32, and calling FormatMessage() with the error code 
> so that the message is set automatically.  If you would like to post patches 
> toward making lldb::Error better handle the case when type == 
> eErrorTypeWin32, that would be very welcome.
> 
> BTW, where is this particular call to Error::SetErrorToErrno() that this is 
> coming from?
> 
> 
> On Thu, Aug 28, 2014 at 11:53 AM, Ted Woodward <ted.woodw...@codeaurora.org> 
> wrote:
> I have a python script that automatically launches a simulator and connects 
> to it with gdb-remote. Everything works fine on Linux. But when I issue the 
> “kill” command on Windows, LLDB crashes.
> 
>  
> 
> This only happens if I launch the simulator (or any external program) using 
> python. I’m using subprocess.Popen, but I’ve also tried os.spawnl. I’ve 
> traced the problem down to reading errno in Error::SetErrorToErrno(). In this 
> case, errno is 0, so no error is reported, and the -1 that recv returns is 
> used as a buffer size and LLDB crashes. If I don’t launch a program using 
> Popen, errno is 2, and everything is handled correctly.
> 
>  
> 
> Stepping into the errno access, GetLastError() is correctly set to 
> WSAECONNRESET, but ptd->_terrno, which errno is set to, is 0. This seems like 
> a Visual Studio 2012 runtime bug.
> 
>  
> 
> I think maybe we shouldn’t rely on errno on Windows, but call GetLastError() 
> and convert their error numbers to POSIX error values.
> 
>  
> 
> Ted
> 
>  
> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev


_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Reply via email to