[lldb-dev] break on exceptions/windows
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
Re: [lldb-dev] break on exceptions/windows
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 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] break on exceptions/windows
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] [Bug 27199] New: test infra: an exceptional exit outside of any test method should be cleared on rerun with no exceptional exit
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 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified Currently all test issues (timeout, exceptional exit, failure, unexpected success, etc.) are tracked to the method they are running within. When no test method was running, the charging of process level events like exceptional exits and timeouts really don't have enough info to assign the issue to a test method, and thus don't have a great way to figure out if the rerun clears that issue. And right now the rerun won't clear events that get tagged to the process level. However, there is one case that seems to me to be crystal clear: if the running of the test methods in a file causes an exceptional exit, and we then rerun that file, if there is no exceptional exit on the rerun, we should be good. It seems like if we're rerunning a file's set of test methods, we could clear file-level issues. If they happen again, we'll pick them up again and report them. If they don't happen, then the rerun addressed whatever was initially causing the issue. Here's one recent example on the OS X Green Dragon llvm.org builder: http://lab.llvm.org:8080/green/job/lldb_build_test/17392/console === [SNIP] === Rerunning the following files: functionalities/thread/state/TestThreadStates.py rerun will use the 'threading' test runner strategy Testing: 1 test suites, 1 thread 0 out of 1 test suites processed - 1 out of 1 test suites processed - TestThreadStates.py Test rerun complete = Issue Details = ERROR: [EXCEPTIONAL EXIT 6 (SIGABRT)] (functionalities/thread/state/TestThreadStates.py) === Test Result Summary === Test Methods: 1694 Reruns:2 Success:1403 Expected Failure: 79 Failure: 0 Error: 0 Exceptional Exit: 1 Unexpected Success: 16 Skip:195 Timeout: 0 Expected Timeout: 0 Command /usr/bin/python failed with exit code 1 ** BUILD FAILED ** === [SNIP] === We reran, did not hit the exceptional exit on rerun, but then still failed the build because we currently only replace test-method-level issues on reruns. (i.e. we replace whatever we had for the test before with what we had for the test now). We essentially need the same flow for wrapping up a file: if we make it all the way through the file without a timeout or exceptional exit, then file-level timeouts/exceptional exits can be cleared. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 27199] test infra: an exceptional exit outside of any test method should be cleared on rerun with no exceptional exit
https://llvm.org/bugs/show_bug.cgi?id=27199 Todd Fiala changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|lldb-dev@lists.llvm.org |todd.fi...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] break on exceptions/windows
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 0xC005" 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 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
Re: [lldb-dev] break on exceptions/windows
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 > 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 > 0xC005" 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 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
Re: [lldb-dev] break on exceptions/windows
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 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 >> 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 >> 0xC005" 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 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
Re: [lldb-dev] break on exceptions/windows
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.g. int 3) 0x8004 Single Step 0xC005 Access violation 0xC01D Illegal Instruction 0xC095 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 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 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 0xC005" 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 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
[lldb-dev] Green Dragon LLDB Xcode build update: TSAN support
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 point in the future, we will change this to a matrix of important clang/clang++ versions (e.g. some number of official Xcode-released clangs). For now, however, we'll continue to build with just one, and that one will be the one in the clang build tree. 2. The Xcode llvm/clang build step now includes compiler-rt and libcxx. This, together with the change above, will allow the newer LLDB TSAN tests to run. If you're ever curious how the Xcode build is run, it uses the build.py script in the zorg repo (http://llvm.org/svn/llvm-project/zorg/trunk) under zorg/jenkins/build.py. The build constructs the build tree with a "derive-lldb" command, and does the Xcode build with the "lldb" command. Please let me know if you have any questions. I'll address any hiccups that may show up ASAP. Thanks! -- -Todd ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] break on exceptions/windows
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 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 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 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 > 0x8003 Breakpoint (e.g. int 3) > 0x8004 Single Step > 0xC005 Access violation > 0xC01D Illegal Instruction > 0xC095 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. >
Re: [lldb-dev] break on exceptions/windows
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 that is conditional on the *target* rather than the host? Then, for example, you could have something like this: (lldb) help break set ... --code ( --code ) [Windows Target] Break when the exception with 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 wrote: > 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 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 > > 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 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 > > 0x8003 Breakpoint (e.g. int 3) > > 0x8004 Single Step > > 0xC005 Access violation > > 0xC01D Illegal Instruction > > 0xC095 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 na
Re: [lldb-dev] break on exceptions/windows
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 exception: (lldb) breakpoint set --exception-name "Integer overflow" Where the name would be passed on to the platform and allow the platform to set the exception breakpoint as it sees fit? If the option was used incorrectly we could query the current platform for all exception names and display them and probably add a command line command that could list all exception codes and names so that it would be discoverable. Greg > On Apr 4, 2016, at 11:17 AM, Jim Ingham wrote: > > 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 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 > > 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 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 >> 0x8003 Breakpoint (e.g. int 3) >> 0x8004 Single Step >> 0xC005 Access violation >> 0xC01D Illegal Instruction >> 0xC095 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
Re: [lldb-dev] break on exceptions/windows
> 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. > > 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 ( --code ) > [Windows Target] Break when the exception with code is > raised. > > How to plumb this to the ProcessWindows plugin is an open question, but > should be mostly mechanical. This is like my suggestion of: (lldb) breakpoint set --exception-code 0x40010005 The code can be passed to the current Platform along with the current target: Error Platform::SetExceptionBreakpointWithExceptionCode (lldb_private::Target *target, uint64_t exception_code); The process can be extracted from the target when the breakpoint needs to be resolved. > On Mon, Apr 4, 2016 at 11:17 AM Jim Ingham wrote: > 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 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 > > 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 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 > > 0x8003 Breakpoint (e.g. int 3) > > 0x8004 Single Step > > 0xC005 Access violation > > 0xC01D Illegal Instruction > > 0xC095 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
Re: [lldb-dev] break on exceptions/windows
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 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 ( --code ) [Windows Target] Break when the exception with code is raised. How to plumb this to the ProcessWindows plugin is an open question, but should be mostly mechanical. This is like my suggestion of: (lldb) breakpoint set --exception-code 0x40010005 The code can be passed to the current Platform along with the current target: Error Platform::SetExceptionBreakpointWithExceptionCode (lldb_private::Target *target, uint64_t exception_code); The process can be extracted from the target when the breakpoint needs to be resolved. There should be a way then to do a "break on every exception", instead of just 1 specific code. and some way for the api to get the payload (which can have a variable number of parameters) -- 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] break on exceptions/windows
> 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 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 >>> that is conditional on the *target* rather than the host? Then, for >>> example, you could have something like this: >>> >>> (lldb) help break set >>> ... >>>--code ( --code ) >>> [Windows Target] Break when the exception with code is >>> raised. >>> >>> How to plumb this to the ProcessWindows plugin is an open question, but >>> should be mostly mechanical. >> >> This is like my suggestion of: >> >> (lldb) breakpoint set --exception-code 0x40010005 >> >> The code can be passed to the current Platform along with the current target: >> >> Error Platform::SetExceptionBreakpointWithExceptionCode >> (lldb_private::Target *target, uint64_t exception_code); >> >> The process can be extracted from the target when the breakpoint needs to be >> resolved. >> >> > > 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 some way for the api to get the payload (which can have a variable number > of parameters) What are you thinking here? Example? > > -- > 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] break on exceptions/windows
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 structure this is: break set -P -key "KEY" -value "VALUE" Jim > 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 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 >>> that is conditional on the *target* rather than the host? Then, for >>> example, you could have something like this: >>> >>> (lldb) help break set >>> ... >>>--code ( --code ) >>> [Windows Target] Break when the exception with code is >>> raised. >>> >>> How to plumb this to the ProcessWindows plugin is an open question, but >>> should be mostly mechanical. >> >> This is like my suggestion of: >> >> (lldb) breakpoint set --exception-code 0x40010005 >> >> The code can be passed to the current Platform along with the current target: >> >> Error Platform::SetExceptionBreakpointWithExceptionCode >> (lldb_private::Target *target, uint64_t exception_code); >> >> The process can be extracted from the target when the breakpoint needs to be >> resolved. >> >> > > There should be a way then to do a "break on every exception", instead of > just 1 specific code. > > and some way for the api to get the payload (which can have a variable number > of parameters) > > -- > 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] break on exceptions/windows
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 some way for the api to get the payload (which can have a variable number of parameters) What are you thinking here? Example? I have a frontend language (and I imagine lots of others have one) where I can throw exceptions. Windows has no predefined way of how an exception object is formatted, you give it a list of pointer sized ints and a count, and that's what it fills the exception object with, for example I pass: [0] Return address [1] frame pointer [2] Class instance of the exception object with my custom exception code. msvc does the same with completely different values. Other languages will have their own values. When using the api I would want access to the code (To know of it's mine, these are the cods Zachery Turner mentioned) and the payload (to get access to the object) so that I show what exception occurred and turn it into a string representation. --- 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] break on exceptions/windows
> 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 be easy with the --exception-name: >> >> (lldb) breakpoint set --exception-name=all >> >>> and some way for the api to get the payload (which can have a variable >>> number of parameters) >> >> What are you thinking here? Example? > > I have a frontend language (and I imagine lots of others have one) where I > can throw exceptions. Windows has no predefined way of how an exception > object is formatted, you give it a list of pointer sized ints and a count, > and that's what it fills the exception object with, for example I pass: > [0] Return address > [1] frame pointer > [2] Class instance of the exception object > with my custom exception code. > > msvc does the same with completely different values. Other languages will > have their own values. When using the api I would want access to the code (To > know of it's mine, these are the cods Zachery Turner mentioned) and the > payload (to get access to the object) so that I show what exception occurred > and turn it into a string representation. Language exceptions are a general class of thing, and those should all be treated similarly if possible. The way you would do this for your new language is to would add a LanguageRuntime for your language, and that would implement CreateExceptionBreakpoint using a BreakpointResolverWindowsException for the correct exception code. The Object filtering is done using "BreakpointPreconditions", which are a way for a breakpoint to stick some code that gets called right when the breakpoint is hit before any of the other ShouldStop machinery takes over. When you make the breakpoint you would pass the "thrown object specifier" to the breakpoint, which would make an appropriate precondition that would know how to dig out the object and compare. So you would see: (lldb) breakpoint set -E MyNewLanguage -O MyObjectName This is currently only implemented in Swift, though the needed infrastructure is present in the llvm tree. If there are other things you want to do that aren't generalizable, then we should treat them as opaque data that gets passed to the platform and it will know how to make the resolver & if needed precondition to do the filtering. Jim > > --- > 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] break on exceptions/windows
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 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 structure > this is: > > break set -P -key "KEY" -value "VALUE" > > Jim > > > >> 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 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 that is conditional on the *target* rather than the host? Then, for example, you could have something like this: (lldb) help break set ... --code ( --code ) [Windows Target] Break when the exception with code is raised. How to plumb this to the ProcessWindows plugin is an open question, but should be mostly mechanical. >>> >>> This is like my suggestion of: >>> >>> (lldb) breakpoint set --exception-code 0x40010005 >>> >>> The code can be passed to the current Platform along with the current >>> target: >>> >>> Error Platform::SetExceptionBreakpointWithExceptionCode >>> (lldb_private::Target *target, uint64_t exception_code); >>> >>> The process can be extracted from the target when the breakpoint needs to >>> be resolved. >>> >>> >> >> There should be a way then to do a "break on every exception", instead of >> just 1 specific code. >> >> and some way for the api to get the payload (which can have a variable >> number of parameters) >> >> -- >> 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] break on exceptions/windows
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't have to worry about consistency with other platforms' interfaces. On Mon, Apr 4, 2016 at 1:18 PM Greg Clayton wrote: > 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 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 > structure this is: > > > > break set -P -key "KEY" -value "VALUE" > > > > Jim > > > > > > > >> 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 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 that is conditional on the *target* rather than the host? Then, > for example, you could have something like this: > > (lldb) help break set > ... > --code ( --code ) > [Windows Target] Break when the exception with code > is raised. > > How to plumb this to the ProcessWindows plugin is an open question, > but should be mostly mechanical. > >>> > >>> This is like my suggestion of: > >>> > >>> (lldb) breakpoint set --exception-code 0x40010005 > >>> > >>> The code can be passed to the current Platform along with the current > target: > >>> > >>> Error Platform::SetExceptionBreakpointWithExceptionCode > (lldb_private::Target *target, uint64_t exception_code); > >>> > >>> The process can be extracted from the target when the breakpoint needs > to be resolved. > >>> > >>> > >> > >> There should be a way then to do a "break on every exception", instead > of just 1 specific code. > >> > >> and some way for the api to get the payload (which can have a variable > number of parameters) > >> > >> -- > >> 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] break on exceptions/windows
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 can have their own options that are completely custom. > On Apr 4, 2016, at 1:27 PM, Zachary Turner wrote: > > 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't have to worry about consistency with other > platforms' interfaces. > > On Mon, Apr 4, 2016 at 1:18 PM Greg Clayton wrote: > 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 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 > > structure this is: > > > > break set -P -key "KEY" -value "VALUE" > > > > Jim > > > > > > > >> 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 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 that is conditional on the *target* rather than the host? > Then, for example, you could have something like this: > > (lldb) help break set > ... > --code ( --code ) > [Windows Target] Break when the exception with code is > raised. > > How to plumb this to the ProcessWindows plugin is an open question, but > should be mostly mechanical. > >>> > >>> This is like my suggestion of: > >>> > >>> (lldb) breakpoint set --exception-code 0x40010005 > >>> > >>> The code can be passed to the current Platform along with the current > >>> target: > >>> > >>> Error Platform::SetExceptionBreakpointWithExceptionCode > >>> (lldb_private::Target *target, uint64_t exception_code); > >>> > >>> The process can be extracted from the target when the breakpoint needs to > >>> be resolved. > >>> > >>> > >> > >> There should be a way then to do a "break on every exception", instead of > >> just 1 specific code. > >> > >> and some way for the api to get the payload (which can have a variable > >> number of parameters) > >> > >> -- > >> 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] break on exceptions/windows
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 model than as breakpoints. Jim > On Apr 4, 2016, at 2:28 PM, Greg Clayton wrote: > > 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 can have their own options that are completely > custom. > > > >> On Apr 4, 2016, at 1:27 PM, Zachary Turner wrote: >> >> 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't have to worry about consistency with other >> platforms' interfaces. >> >> On Mon, Apr 4, 2016 at 1:18 PM Greg Clayton wrote: >> 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 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 >>> structure this is: >>> >>> break set -P -key "KEY" -value "VALUE" >>> >>> Jim >>> >>> >>> 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 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 that is conditional on the *target* rather than the host? >> Then, for example, you could have something like this: >> >> (lldb) help break set >> ... >> --code ( --code ) >> [Windows Target] Break when the exception with code is >> raised. >> >> How to plumb this to the ProcessWindows plugin is an open question, but >> should be mostly mechanical. > > This is like my suggestion of: > > (lldb) breakpoint set --exception-code 0x40010005 > > The code can be passed to the current Platform along with the current > target: > > Error Platform::SetExceptionBreakpointWithExceptionCode > (lldb_private::Target *target, uint64_t exception_code); > > The process can be extracted from the target when the breakpoint needs to > be resolved. > > There should be a way then to do a "break on every exception", instead of just 1 specific code. and some way for the api to get the payload (which can have a variable number of parameters) -- 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] break on exceptions/windows
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 that entire commands or subcommands could exist only for certain platforms. There's plenty of commands i want to implement on Windows that have no analogue anywhere else, so at some level i still think we need a way to have dynamic commands and options that only show up for a given platform On Mon, Apr 4, 2016 at 2:40 PM Jim Ingham wrote: > 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 > model than as breakpoints. > > Jim > > > > On Apr 4, 2016, at 2:28 PM, Greg Clayton wrote: > > > > 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 can have their own options that are > completely custom. > > > > > > > >> On Apr 4, 2016, at 1:27 PM, Zachary Turner wrote: > >> > >> 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't have to worry about consistency with other > platforms' interfaces. > >> > >> On Mon, Apr 4, 2016 at 1:18 PM Greg Clayton wrote: > >> 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 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 > structure this is: > >>> > >>> break set -P -key "KEY" -value "VALUE" > >>> > >>> Jim > >>> > >>> > >>> > 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 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 that is conditional on the *target* rather than the host? Then, > for example, you could have something like this: > >> > >> (lldb) help break set > >> ... > >> --code ( --code ) > >> [Windows Target] Break when the exception with code > is raised. > >> > >> How to plumb this to the ProcessWindows plugin is an open question, > but should be mostly mechanical. > > > > This is like my suggestion of: > > > > (lldb) breakpoint set --exception-code 0x40010005 > > > > The code can be passed to the current Platform along with the > current target: > > > > Error Platform::SetExceptionBreakpointWithExceptionCode > (lldb_private::Target *target, uint64_t exception_code); > > > > The process can be extracted from the target when the breakpoint > needs to be resolved. > > > > > > There should be a way then to do a "break on every exception", > instead of just 1 specific code. > > and some way for the api to get the payload (which can have a > variable number of parameters) > > -- > 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] Green Dragon LLDB Xcode build update: TSAN support
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 the failure will require looking at the console log for the build and test job. I'm excited to see our gtest test count has gone from roughly 17 to over 100 now! Pavel or Tamas, are we running the gtests on the Linux buildbots? -Todd On Mon, Apr 4, 2016 at 10:49 AM, Todd Fiala wrote: > 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 point in the future, we will change this to a > matrix of important clang/clang++ versions (e.g. some number of official > Xcode-released clangs). For now, however, we'll continue to build with > just one, and that one will be the one in the clang build tree. > > 2. The Xcode llvm/clang build step now includes compiler-rt and libcxx. > This, together with the change above, will allow the newer LLDB TSAN tests > to run. > > If you're ever curious how the Xcode build is run, it uses the build.py > script in the zorg repo (http://llvm.org/svn/llvm-project/zorg/trunk) > under zorg/jenkins/build.py. The build constructs the build tree with a > "derive-lldb" command, and does the Xcode build with the "lldb" command. > > Please let me know if you have any questions. > > I'll address any hiccups that may show up ASAP. > > Thanks! > -- > -Todd > -- -Todd ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] break on exceptions/windows
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) :
CommandObjectMultiword (interpreter,
"process plugin",
"A set of commands for operating on a
ProcessGDBRemote process.",
"process plugin
[]")
{
LoadSubCommand ("packet", CommandObjectSP (new
CommandObjectProcessGDBRemotePacket(interpreter)));
}
~CommandObjectMultiwordProcessGDBRemote ()
{
}
};
CommandObject *
ProcessGDBRemote::GetPluginCommandObject()
{
if (!m_command_sp)
m_command_sp.reset (new CommandObjectMultiwordProcessGDBRemote
(GetTarget().GetDebugger().GetCommandInterpreter()));
return m_command_sp.get();
}
These commands and then accessed by:
(lldb) process plugin ...
So if there is something that can't be easily fit into an agnostic
implementation, you could fall back onto this.
I don't think this is one of those cases. We should be able to come up with
something that can abstract this well.
Greg
> On Apr 4, 2016, at 2:53 PM, Zachary Turner wrote:
>
> 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
> that entire commands or subcommands could exist only for certain platforms.
> There's plenty of commands i want to implement on Windows that have no
> analogue anywhere else, so at some level i still think we need a way to have
> dynamic commands and options that only show up for a given platform
> On Mon, Apr 4, 2016 at 2:40 PM Jim Ingham wrote:
> 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 model than
> as breakpoints.
>
> Jim
>
>
> > On Apr 4, 2016, at 2:28 PM, Greg Clayton wrote:
> >
> > 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 can have their own options that are
> > completely custom.
> >
> >
> >
> >> On Apr 4, 2016, at 1:27 PM, Zachary Turner wrote:
> >>
> >> 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't have to worry about consistency with other
> >> platforms' interfaces.
> >>
> >> On Mon, Apr 4, 2016 at 1:18 PM Greg Clayton wrote:
> >> 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 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
> >>> structure this is:
> >>>
> >>> break set -P -key "KEY" -value "VALUE"
> >>>
> >>> Jim
> >>>
> >>>
> >>>
> 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 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 that is conditional on the *target* rather than the host?
> >> Then, for example, you could have something like this:
> >>
> >> (lldb) help break set
> >> ...
> >> --code ( --code )
> >> [Windows Target] Break when the exception with code
> >> is raised.
> >>
> >> How to plumb this to the ProcessWindows plugin is an op
Re: [lldb-dev] break on exceptions/windows
"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 putting them under the catch heading, it will be much easier to find the capability if you didn't know that lldb could do that thing already. Also, anything that stops the process is going to have a shared set of options, ignore count, commands, conditions and the like. Even with the option groups managing these is some work, and it makes sense to centralize them. Jim > On Apr 4, 2016, at 2:53 PM, Zachary Turner wrote: > > 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 > that entire commands or subcommands could exist only for certain platforms. > There's plenty of commands i want to implement on Windows that have no > analogue anywhere else, so at some level i still think we need a way to have > dynamic commands and options that only show up for a given platform > On Mon, Apr 4, 2016 at 2:40 PM Jim Ingham wrote: > 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 model than > as breakpoints. > > Jim > > > > On Apr 4, 2016, at 2:28 PM, Greg Clayton wrote: > > > > 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 can have their own options that are > > completely custom. > > > > > > > >> On Apr 4, 2016, at 1:27 PM, Zachary Turner wrote: > >> > >> 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't have to worry about consistency with other > >> platforms' interfaces. > >> > >> On Mon, Apr 4, 2016 at 1:18 PM Greg Clayton wrote: > >> 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 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 > >>> structure this is: > >>> > >>> break set -P -key "KEY" -value "VALUE" > >>> > >>> Jim > >>> > >>> > >>> > 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 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 that is conditional on the *target* rather than the host? > >> Then, for example, you could have something like this: > >> > >> (lldb) help break set > >> ... > >> --code ( --code ) > >> [Windows Target] Break when the exception with code > >> is raised. > >> > >> How to plumb this to the ProcessWindows plugin is an open question, > >> but should be mostly mechanical. > > > > This is like my suggestion of: > > > > (lldb) breakpoint set --exception-code 0x40010005 > > > > The code can be passed to the current Platform along with the current > > target: > > > > Error Platform::SetExceptionBreakpointWithExceptionCode > > (lldb_private::Target *target, uint64_t exception_code); > > > > The process can be extracted from the target when the breakpoint needs > > to be resolved. > > > > > > There should be a way then to do a
[lldb-dev] [Bug 27205] New: TestThreadStates: StringExtractorGDBRemote.cpp packet validation failure
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 Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified I'm seeing this occasionally on the OS X LLDB CI: Assertion failed: (!"Packet validatation failed, check why this is happening"), function OKErrorNotSupportedResponseValidator, file /Users/buildslave/jenkins/sharedspace/lldb@2/lldb/source/Utility/StringExtractorGDBRemote.cpp, line 408. [TestThreadStates.py FAILED] leading to an exceptional exit. The CI runs with the local Xcode's Apple-signed debugserver, not the debugserver source in the LLDB tree. This shouldn't matter, but I'm calling it out in case it does. Seems a little extreme that we're asserting on gdb packet handling? In any event, we need to track this down since it is starting to happen with some regularity. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 27205] TestThreadStates: StringExtractorGDBRemote.cpp packet validation failure
https://llvm.org/bugs/show_bug.cgi?id=27205 Todd Fiala changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|lldb-dev@lists.llvm.org |clayb...@gmail.com --- Comment #1 from Todd Fiala --- Assigning over to Greg. He recently tweaked this code, and it is related to a change in debugserver. This might either require a new debugserver (in which case the CI has to run on a bot with all the lldb_codesign magic set, which is something we're trying to avoid over at LLVM.org due to build machine pooling interests), or an adjustment for what is considered okay with older debugservers. Either way, we have something to investigate. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
