On Fri, Sep 8, 2017 at 8:19 PM Jason Molenda wrote:
> Also keep in mind that debug sessions have a tendency to be long lived. I
> may be working through a problem for half an hour -- or this may be the one
> rare instance where a bug reproduces -- and crashing because some bogus
> piece of debug
Just to comment on one aside from earlier, about the fact that Apple moved lldb
out of process from Xcode. This was necessitated by some swift support issues,
but it's true that the fact that lldb crashing no longer took down Xcode was a
big plus to moving lldb out of process. This shouldn't b
Also keep in mind that debug sessions have a tendency to be long lived. I may
be working through a problem for half an hour -- or this may be the one rare
instance where a bug reproduces -- and crashing because some bogus piece of
debug info that I don't care about is invalid is not acceptable.
Yes, the fact that llvm & clang and the MCJIT abort willy nilly has caused much
pain to lldb. We don’t control that behavior and so are resigned to some
continued suffering along those lines - though it seems like Lang is going to
do a much cleaner job of handling problems in the new ORC JIT wh
Note that if something originates from user input, then i agree there's no
excuse for a fail fast. But after all the inputs have been sanitized, I
think it's fine to fast fail
On Fri, Sep 8, 2017 at 7:12 PM Zachary Turner wrote:
> On Fri, Sep 8, 2017 at 6:11 PM Jim Ingham via Phabricator <
> revi
On Fri, Sep 8, 2017 at 6:11 PM Jim Ingham via Phabricator <
revi...@reviews.llvm.org> wrote:
>
> I know there is debate about this one side and another but for lldb this
> is a settled issue. Unless you really are in a state where the world is
> about to come crashing down around you, you can't r
jingham added a comment.
And I don't understand your answer to Adrian. In the case of core files,
DoResume is clearly failing so if the error WERE handled correctly, why would
there be any work needed?
https://reviews.llvm.org/D37651
___
lldb-com
jingham added a comment.
As for the overdetermined remark, it's what you suspect, that you are now
asking two questions to get one answer, did the resume succeed. If the resume
didn't succeed the state should be set back to stopped no matter why it didn't
succeed. So you are fixing only one s
jingham added a comment.
lldb is a library used in other programs (Xcode, VSCode etc) and it can support
many simultaneous debug sessions and each debug session can support many
simultaneous targets. Unless this failure is going to make all the other debug
sessions fail, and the other target s
lemo added a comment.
Thanks everyone for the feedback.
I see a common question is why doesn't DoResume() fail-fast itself, or why
don't the callers propagate the error. It's a good question, since the
knowledge if a subclass can resume or not is almost codified in there. The
problem is that t
Author: compnerd
Date: Fri Sep 8 17:13:49 2017
New Revision: 312841
URL: http://llvm.org/viewvc/llvm-project?rev=312841&view=rev
Log:
Plugins: fix resolution ambiguity in PDB plugin
A clang change caused the inclusion of `llvm::Type` and
`lldb_private::Type` to be pulled into the global namespac
amccarth added a comment.
I think I agree with Jim that it would be better to propagate an error from
DoResume than to introduce CanResume. I could imagine situations where
DoResume could fail for a reason that CanResume was unable to predict. Having
one path for handling failure to resume se
jingham added a comment.
But whatever the solution, you should never use llvm::report_fatal_error. It's
fine to put in an lldb_assert which will assert when the error is hit in the
test suite, but not in released lldb's. After all, the worst that will happen
if somebody working on lldb were t
jingham requested changes to this revision.
jingham added a comment.
This seems like an awkward solution to me. Having CanResume and DoResume seems
like it over-determines the problem.
Why wasn't it enough for DoResume to fail and the error to be propagated?
I'm also uncomfortable that this is
sas requested changes to this revision.
sas added a comment.
This revision now requires changes to proceed.
I think it would be cleaner/smaller if you didn't use pure-virtual functions,
but instead you had `CanReseume()` return `false` in `Process.h`, and had a
default implementation of `DoResum
lemo created this revision.
The main change is to avoid setting the process state as running when debugging
core/minidumps (details in the bug).
Also included a few small, related fixes around how the errors propagate in
this case.
https://reviews.llvm.org/D37651
Files:
include/lldb/Target
Hello everyone,
Below are some buildbot numbers for the last week of 08/27/2017 -
09/02/2017.
Please see the same data in attached csv files:
The longest time each builder was red during the last week;
"Status change ratio" by active builder (percent of builds that changed the
builder status fro
Hello everyone,
Below are some buildbot numbers for last the week of 08/20/2017 -
08/26/2017.
Please see the same data in attached csv files:
The longest time each builder was red during the last week;
"Status change ratio" by active builder (percent of builds that changed the
builder status fro
Hello everyone,
Below are some buildbot numbers for the week of 08/13/2017 - 08/19/2017.
Please see the same data in attached csv files:
The longest time each builder was red during the last week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from gre
Hello everyone,
Below are some buildbot numbers for the week of 08/06/2017 - 08/12/2017.
Please see the same data in attached csv files:
The longest time each builder was red during the last week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from gre
Hello everyone,
Below are some buildbot numbers for the week of 07/23/2017 - 07/29/2017.
Please see the same data in attached csv files:
The longest time each builder was red during the last week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from gre
Hello everyone,
Below are some buildbot numbers for the week of 07/30/2017 - 08/05/2017.
Please see the same data in attached csv files:
The longest time each builder was red during the last week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from gre
Hello everyone,
Below are some buildbot numbers for the week of 07/16/2017 - 07/22/2017.
Please see the same data in attached csv files:
The longest time each builder was red during the last week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from gre
23 matches
Mail list logo
