[lldb-dev] exception "leaks" to debugger for win32

[Greg Clayton via lldb-dev]

Ok, sounds like there is platform level precedence to support this flow and things should stay this way to keep Windows user experience consistent with other debuggers. Thanks for the info.

Greg

> On Mar 18, 2016, at 11:42 AM, Zachary Turner <zturner at google.com> wrote:
> 
> FWIW all the debuggers that people normally use on windows show it this way as well.  The reason is that by default, if you do nothing and simply launch a program under a debugger, you hit a breakpoint.  There's no way to avoid it, it's done by the loader at the OS level.  If someone doesn't want to stop at entry point (e.g. doesn't specify -s), we go out of our way to mask it.  So seeing that a breakpoint was hit on startup, while not consistent with LLDB on other platforms, is consistent with other debuggers on Windows.  For example, on WinDbg, I get this:
> 
> CommandLine: D:\infinite.exe
> Symbol search path is: *** Invalid ***
> ****************************************************************************
> * Symbol loading may be unreliable without a symbol search path.           *
> * Use .symfix to have the debugger choose a symbol path.                   *
> * After setting your symbol path, use .reload to refresh symbol locations. *
> ****************************************************************************
> Executable search path is: 
> ModLoad: 00940000 009f8000   infinite.exe
> ModLoad: 770e0000 7725b000   ntdll.dll
> ModLoad: 74570000 74650000   C:\WINDOWS\SysWOW64\KERNEL32.DLL
> ModLoad: 747a0000 7491e000   C:\WINDOWS\SysWOW64\KERNELBASE.dll
> ModLoad: 723e0000 72472000   C:\WINDOWS\SysWOW64\apphelp.dll
> ModLoad: 743e0000 7445b000   C:\WINDOWS\SysWOW64\ADVAPI32.dll
> ModLoad: 760b0000 7616e000   C:\WINDOWS\SysWOW64\msvcrt.dll
> ModLoad: 74460000 744a4000   C:\WINDOWS\SysWOW64\sechost.dll
> ModLoad: 76000000 760ad000   C:\WINDOWS\SysWOW64\RPCRT4.dll
> ModLoad: 73e10000 73e2e000   C:\WINDOWS\SysWOW64\SspiCli.dll
> ModLoad: 73e00000 73e0a000   C:\WINDOWS\SysWOW64\CRYPTBASE.dll
> ModLoad: 74a80000 74ad8000   C:\WINDOWS\SysWOW64\bcryptPrimitives.dll
> (acc0.9894): Break instruction exception - code 80000003 (first chance)
> *** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll - 
> eax=00000000 ebx=00000003 ecx=eaea0000 edx=00000000 esi=009400f8 edi=0029e000
> eip=7718ccbc esp=0018f4e4 ebp=0018f510 iopl=0         nv up ei pl zr na pe nc
> cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
> ntdll!LdrInitShimEngineDynamic+0x6dc:
> 7718ccbc cc              int     3
> 
> 
> Then you have to manually continue to skip this.  But it's still an int 3 and shows up in the debugger no different than any other int 3 to the user.
> 
> On Fri, Mar 18, 2016 at 11:36 AM Greg Clayton via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> Anything exception that is done by the implementation in order to implement normally stopping at the entry point should be covered up and not sent to the user. A thread has the notion of a private stop info and one that is produced for the public consumption. If this exception is indeed only showing up because this is the way we were able to stop at the entry point, we should not be showing that to the user.
> 
> > On Mar 18, 2016, at 11:24 AM, Carlo Kok via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> >
> > When starting a process on Win32 there's an internal exception (breakpint) that leaks to the debug caller:
> > s     'Exception 0x80000003 encountered at address 0x7789ccbc'#0
> >
> > This one is dealt with by the debugger internally but there's still a StateType.eStateStopped event for it. On other platforms there's no exception like this for the internal start breakpoint (note that actual breakpoints after this hit just fine)
> >
> > --
> > Carlo Kok
> > RemObjects Software
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev