How do I break on (first chance) exceptions on Windows?
--
Carlo Kok
RemObjects Software
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Not possible currently, although it wouldn't be too hard to add. Would be a
welcome feature if you are interested
On Mon, Apr 4, 2016 at 2:05 AM Carlo Kok via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> How do I break on (first chance) exceptions on Windows?
>
> --
> Carlo Kok
> RemObjects Softwa
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
__
https://llvm.org/bugs/show_bug.cgi?id=27199
Bug ID: 27199
Summary: test infra: an exceptional exit outside of any test
method should be cleared on rerun with no exceptional
exit
Product: lldb
Version: unspecified
https://llvm.org/bugs/show_bug.cgi?id=27199
Todd Fiala changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|lldb-dev@lists.llvm.or
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 ExceptionR
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
> wrot
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 o
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
0x8003 Breakpoint (e
Hi all,
I've made a minor change to the Green Dragon LLDB OS X Xcode build located
here:
http://lab.llvm.org:8080/green/job/LLDB/
1. Previously, the python test run used the default C/C++ compiler to build
test inferiors. Now it uses the just-built clang/clang++ to build test
inferiors. At some
Interesting.
For the other windows exceptions, could we do something abstract like:
(lldb) break set --platform
(-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 breakpoin
It seems like we already have some precedent for conditional command
arguments. For example:
(lldb) help platform process list
...
-u ( --uid )
[POSIX] Find processes that have a matching user ID.
So on Windows this argument doesn't make sense. Could we make an argument
tha
One easy way to abstract this would be to allow a "--exception-code" option:
(lldb) breakpoint set --exception-code 0x40010005
This would pass through to the platform and ask each platform to make a
breakpoint using the platform specific code.
We could also add a similar option that names the e
> On Apr 4, 2016, at 11:24 AM, Zachary Turner wrote:
>
> It seems like we already have some precedent for conditional command
> arguments. For example:
>
> (lldb) help platform process list
> ...
>-u ( --uid )
> [POSIX] Find processes that have a matching user ID.
>
> S
Op 2016-04-04 om 20:30 schreef Greg Clayton:
On Apr 4, 2016, at 11:24 AM, Zachary Turner wrote:
It seems like we already have some precedent for conditional command arguments.
For example:
(lldb) help platform process list
...
-u ( --uid )
[POSIX] Find processes th
> On Apr 4, 2016, at 11:36 AM, Carlo Kok wrote:
>
>
>
> Op 2016-04-04 om 20:30 schreef Greg Clayton:
>>
>>> On Apr 4, 2016, at 11:24 AM, Zachary Turner wrote:
>>>
>>> It seems like we already have some precedent for conditional command
>>> arguments. For example:
>>>
>>> (lldb) help plat
Yes, that's why I prefer a more abstract command interface than trying to be
too specific about some abstract breakpoint. So you'd just have:
Error
Platform::SetPlatformBreakpoint(lldb_private::Target *target, const char *data);
Then this can have any meaning that it needs to. The other way to
Op 2016-04-04 om 20:41 schreef Greg Clayton:
On Apr 4, 2016, at 11:36 AM, Carlo Kok wrote:
There should be a way then to do a "break on every exception", instead of just
1 specific code.
That would be easy with the --exception-name:
(lldb) breakpoint set --exception-name=all
and
> On Apr 4, 2016, at 11:48 AM, Carlo Kok wrote:
>
>
>
> Op 2016-04-04 om 20:41 schreef Greg Clayton:
>>
>>> On Apr 4, 2016, at 11:36 AM, Carlo Kok wrote:
>
>>>
>>> There should be a way then to do a "break on every exception", instead of
>>> just 1 specific code.
>>
>> That would b
I really would rather avoid the key/value thing. I prefer the --exception-name
and --exception-code and have the platform handle it. Seems cleaner.
Greg
> On Apr 4, 2016, at 11:41 AM, Jim Ingham wrote:
>
> Yes, that's why I prefer a more abstract command interface than trying to be
> too spec
Another option would be to have sub-sub commands. Already when you mix so
many options together, lots of the options don't make sense with each
other. What about
break set windows --exc-code=0xC005
This way all the windows specific stuff is wrapped up behind another
subcommand, and you don'
We could add a "platform breakpoint set" command as a new stand alone
breakpoint mechanism and avoid messing with the "breakpoint set" command at
all.
(lldb) platform breakpoint set ...
This would be passed to the current lldb_private::Platform plug-in for it to
parse as needed. Each platform
If we're going this far, then we should just add a "catch" command, and have
the platforms be able to add "catchable" things. For instance, you could catch
shared library loads, you could catch fork & exec, maybe IPC message sends and
Windows exceptions. Seems like they fit better in this mode
Calling everything "catch" is a bit too much of a catch-all though (excuse
the pun).
I like the idea of every command being able to have a platform specific sub
command, similar to gregs suggested "platform break set".
But I think you need a way to make commands themselves platform specific so
th
One more update:
The Green Dragon OS X LLDB builder now actually runs the gtests instead of
just building them.
The gtests run as a phase right before the Python test suite. A non-zero
value returning from the gtests will cause the OS X LLDB build to fail.
Right now, tracking down the cause of t
FYI: there is already a way for process plug-ins to add their own commands. If
we look at ProcessGDBRemote:
class CommandObjectMultiwordProcessGDBRemote : public CommandObjectMultiword
{
public:
CommandObjectMultiwordProcessGDBRemote (CommandInterpreter &interpreter) :
CommandObjectMu
"catch" would be for stopping on any process life-cycle events that aren't
watchpoints or breakpoints (thread creation, spawning, etc are other examples.)
That seems quite well-defined to me. And I like that the ways you can stop a
program are not scattered throughout the command set. By putt
https://llvm.org/bugs/show_bug.cgi?id=27205
Bug ID: 27205
Summary: TestThreadStates: StringExtractorGDBRemote.cpp packet
validation failure
Product: lldb
Version: unspecified
Hardware: PC
OS: All
https://llvm.org/bugs/show_bug.cgi?id=27205
Todd Fiala changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|lldb-dev@lists.llvm.or
29 matches
Mail list logo
