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

[Zachary Turner via lldb-dev]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160318/6a5ad30f/attachment.html>