[lldb-dev] break on exceptions/windows

[Zachary Turner via lldb-dev]

Windows works a little differently.  Windows has the notion of a Windows
exception, which the best way I can describe it is like a signal.  But it's
an arbitrary 32-bit value, and there are hundreds, if not thousands of
different values.  here's a few:

0x40010005   Ctrl+C
0x80000003  Breakpoint (e.g. int 3)
0x80000004  Single Step
0xC0000005  Access violation
0xC000001D  Illegal Instruction
0xC0000095  Integer overflow
0xE06D7363 C++ Exception

Note the last one.  It's interesting, because it illustrates that on
Windows, C++ exceptions are just Windows exceptions with a different code.
And if you were to implement some other programming language such as swift
on Windows, you would probably even do it the same way, by finding an
unused exception code and raising it with your language-specific exception
context.

When any of these happen in the inferior, the debugger gets a notification
(called a first-chance exception), and the debugger can decide what to do,
such as break into the debugger, or ignore it and pass it on to the
application

It's possible this makes more sense as a windows specific debugger command,
or perhaps a windows specific subcommand of the "break" command that is
only available if the selected target is windows.

Existing Windows debuggers allow exception breakpoints of this nature
through a consistent interface, with the ability to drill down into
different types of exceptions.  What I mean is, you can set the debugger to
stop on all access violations or all C++ exceptions, but you can get more
advanced for C++ exceptions and set an exception when a specific type is
thrown (like a std::string, for example).  The debugger would implement
this by installing a 0xE06D7363 exception breakpoint, and ignoring any
where the type wasn't std::string (by analyzing the context record).

So, there is at least one aspect of this work that shares some behavior
with how C++ language exceptions might work with clang on non-Windows
platforms.  Being able to say "break when a std::string is thrown" is not
OS-specific and very useful.

But the other aspect is not, and there's not an obvious way to present a
consistent interface (e.g. command line command) to the OS-independent
functionality across platforms, while also presenting a consistent
interface to the OS specific functionality on Windows.

On Mon, Apr 4, 2016 at 10:23 AM Jim Ingham <jingham at apple.com> wrote:

> The exception breakpoints Greg is talking about are language exceptions
> (C++ throws, Swift Errors and the like.)
>
> I don't know what kind of exception you are talking about here, but at
> least from a command interface standpoint, it would be good to keep alike
> things that actually are alike, but only if they ARE actually alike.
>
> Jim
>
> > On Apr 4, 2016, at 10:07 AM, Greg Clayton <gclayton at apple.com> wrote:
> >
> > You should talk to Jim Ingham on this. We have special exception
> breakpoints that we did for Swift and you will want to follow the same
> methodology. I am not sure what the methodology is so I'm CC'ing Jim so can
> can comment.
> >
> > Greg
> >> On Apr 4, 2016, at 9:52 AM, Zachary Turner via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> >>
> >> Take a look at ProcessWindowsLive.cpp in Plugins/Process/Windows.
> There's a function called ProcessWindowsLive::OnDebugException.  If you're
> working in a fork and you don't intend to upstream any changes, you could
> just modify the default case of the switch statement there to not return
> ExceptionResult::SendToApplication.
> >>
> >> If you wanted to upstream something, you'd probably want a way to
> specify what types of exceptions to break on.  For this you'd need to
> implement a new command so that you could do something like "break set
> --exception 0xC0000005" and pass that information to the ProcessWindowsLive
> plugin somehow, so that it could decide when to break and when to pass it
> on to the application for a second chance.
> >>
> >> On Mon, Apr 4, 2016 at 8:26 AM Carlo Kok <ck at remobjects.com> wrote:
> >>
> >>
> >> Op 2016-04-04 om 16:00 schreef Zachary Turner:
> >>> Not possible currently, although it wouldn't be too hard to add. Would
> >>> be a welcome feature if you are interested
> >>
> >>
> >> I'm (obviously?) interested. But wouldn't know where to start.
> >>
> >> --
> >> Carlo Kok
> >> RemObjects Software
> >> _______________________________________________
> >> 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/20160404/b957a575/attachment.html>