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@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@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@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
