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

Zachary Turner via lldb-dev lldb-dev at lists.llvm.org
Fri Mar 18 11:42:07 PDT 2016

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
eip=7718ccbc esp=0018f4e4 ebp=0018f510 iopl=0         nv up ei pl zr na pe
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b
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>

More information about the lldb-dev mailing list