"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
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
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
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
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
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'
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
> 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
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
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
> 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
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: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
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
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
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
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
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
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
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
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
__
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
22 matches
Mail list logo
