It seems like we already have some precedent for conditional command
arguments. For example:
(lldb) help platform process list
...
-u <unsigned-integer> ( --uid <unsigned-integer> )
[POSIX] Find processes that have a matching user ID.
So on Windows this argument doesn't make sense. Could we make an argument
that is conditional on the *target* rather than the host? Then, for
example, you could have something like this:
(lldb) help break set
...
--code <hex-integer> ( --code <hex-integer> )
[Windows Target] Break when the exception with code <code> is
raised.
How to plumb this to the ProcessWindows plugin is an open question, but
should be mostly mechanical.
On Mon, Apr 4, 2016 at 11:17 AM Jim Ingham <jing...@apple.com> wrote:
> Interesting.
>
> For the other windows exceptions, could we do something abstract like:
>
> (lldb) break set --platform <data>
>
> (-P for short) to set a "platform breakpoint", where "data" is a string
> that the current platform will understand, but the breakpoint machinery
> doesn't have to.
>
> The way breakpoints work internally is that somebody provides a
> "BreakpointResolver" subclass which gets called when anything interesting
> happens in the program (rerun, shared library load, etc). It's the
> BreakpointResolver's job to add locations to the breakpoint, describe
> itself and the like. But this is a fairly abstract interface, and it
> wouldn't be hard to have a Platform function that got passed "data" and
> returned a breakpoint resolver to turn on the watch for these exceptions.
>
> Then when the breakpoint gets set, the model is Breakpoints have
> "BreakpointLocations" which each add one place a stop might occur: a
> "BreakpointSite". The division between Sites & Locations is because two
> logically different Locations could map to the same physical Site. Then
> the Sites are used at the lowest level to map a stop reason back into the
> breakpoint(s) that caused it. To date, the only BreakpointSites are PC
> based, so the BreakpointList gets asked "is there a site at this PC". But
> that all happens in the process plugins, so it wouldn't be hard to map
> other stop reasons to particular sites. The lower layers of the process
> (e.g. ProcessGDBRemote) figure out which site maps to the stop reason, and
> makes a StopInfoBreakpoint with that BreakpointSite. And after that the
> Site -> Location -> Breakpoint logic is done w/o much care how the Site
> actually works.
>
>
> WRT language exceptions in specific, in lldb you say:
>
> (lldb) break set -E c++
>
> to break on C++ exception throws. You would say:
>
> (lldb) break set -E c++ -O <OBJECT_NAME>
>
> to restrict the exception throw to a particular object type, except I
> haven't implemented this for anything but Swift errors yet, but it wouldn't
> be hard to do that. So regardless of what we do with the other Windows
> exceptions, we should implement the language exceptions consistently this
> way at the command line level just to keep things consistent. But again,
> once we're able to hand out "BreakpointResolverWindowsExceptions" in
> general, we could create them on Windows for the C++ ABI as well (another
> reason you'll probably want a Windows C++ language runtime since it's the
> itanium ABI that does this job on other platforms. The object filtering is
> mostly runtime ABI work - to figure out the thrown exception from the throw
> site. But that's just some ABI function that the general matching code
> would call.
>
> This would be some work, for sure, but I don't think it would be terribly
> hard to do.
>
> Jim
>
>
>
>
> > On Apr 4, 2016, at 10:46 AM, Zachary Turner <ztur...@google.com> wrote:
> >
> > 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 <jing...@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 <gclay...@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@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 <c...@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@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
