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

[Zachary Turner via lldb-dev]

Are you launching the process with -s (stop at entry)?

On Fri, 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 0x8003 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

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

[Carlo Kok via lldb-dev]

ah yes! Disabling that fixed it. Thanks

Op 2016-03-18 om 19:29 schreef Zachary Turner:

Are you launching the process with -s (stop at entry)?

On Fri, Mar 18, 2016 at 11:24 AM Carlo Kok via lldb-dev
> wrote:

When starting a process on Win32 there's an internal exception
(breakpint) that leaks to the debug caller:
s   'Exception 0x8003 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



--
Carlo Kok
RemObjects Software
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [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  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: 0094 009f8000   infinite.exe
> ModLoad: 770e 7725b000   ntdll.dll
> ModLoad: 7457 7465   C:\WINDOWS\SysWOW64\KERNEL32.DLL
> ModLoad: 747a 7491e000   C:\WINDOWS\SysWOW64\KERNELBASE.dll
> ModLoad: 723e 72472000   C:\WINDOWS\SysWOW64\apphelp.dll
> ModLoad: 743e 7445b000   C:\WINDOWS\SysWOW64\ADVAPI32.dll
> ModLoad: 760b 7616e000   C:\WINDOWS\SysWOW64\msvcrt.dll
> ModLoad: 7446 744a4000   C:\WINDOWS\SysWOW64\sechost.dll
> ModLoad: 7600 760ad000   C:\WINDOWS\SysWOW64\RPCRT4.dll
> ModLoad: 73e1 73e2e000   C:\WINDOWS\SysWOW64\SspiCli.dll
> ModLoad: 73e0 73e0a000   C:\WINDOWS\SysWOW64\CRYPTBASE.dll
> ModLoad: 74a8 74ad8000   C:\WINDOWS\SysWOW64\bcryptPrimitives.dll
> (acc0.9894): Break instruction exception - code 8003 (first chance)
> *** ERROR: Symbol file could not be found.  Defaulted to export symbols for 
> ntdll.dll - 
> eax= ebx=0003 ecx=eaea edx= 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=0246
> 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 
>  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 
> >  wrote:
> >
> > When starting a process on Win32 there's an internal exception (breakpint) 
> > that leaks to the debug caller:
> > s 'Exception 0x8003 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

Re: [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: 0094 009f8000   infinite.exe
ModLoad: 770e 7725b000   ntdll.dll
ModLoad: 7457 7465   C:\WINDOWS\SysWOW64\KERNEL32.DLL
ModLoad: 747a 7491e000   C:\WINDOWS\SysWOW64\KERNELBASE.dll
ModLoad: 723e 72472000   C:\WINDOWS\SysWOW64\apphelp.dll
ModLoad: 743e 7445b000   C:\WINDOWS\SysWOW64\ADVAPI32.dll
ModLoad: 760b 7616e000   C:\WINDOWS\SysWOW64\msvcrt.dll
ModLoad: 7446 744a4000   C:\WINDOWS\SysWOW64\sechost.dll
ModLoad: 7600 760ad000   C:\WINDOWS\SysWOW64\RPCRT4.dll
ModLoad: 73e1 73e2e000   C:\WINDOWS\SysWOW64\SspiCli.dll
ModLoad: 73e0 73e0a000   C:\WINDOWS\SysWOW64\CRYPTBASE.dll
ModLoad: 74a8 74ad8000   C:\WINDOWS\SysWOW64\bcryptPrimitives.dll
(acc0.9894): Break instruction exception - code 8003 (first chance)
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for
ntdll.dll -
eax= ebx=0003 ecx=eaea edx= 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=0246
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 0x8003 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

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

[Carlo Kok via lldb-dev]

When starting a process on Win32 there's an internal exception 
(breakpint) that leaks to the debug caller:

s   'Exception 0x8003 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