Author: labath
Date: Wed Jun 20 01:12:50 2018
New Revision: 335102
URL: http://llvm.org/viewvc/llvm-project?rev=335102&view=rev
Log:
BreakpointIDList: Use llvm::ArrayRef instead of pointer+length pair
NFC
Modified:
lldb/trunk/include/lldb/Breakpoint/BreakpointIDList.h
lldb/trunk/source/B
Author: labath
Date: Wed Jun 20 01:35:45 2018
New Revision: 335104
URL: http://llvm.org/viewvc/llvm-project?rev=335104&view=rev
Log:
Remove dependency from Host to python
Summary:
The only reason python was used in the Host module was to compute the
python path. I resolve this the same way as D47
This revision was automatically updated to reflect the committed changes.
Closed by commit rL335104: Remove dependency from Host to python (authored by
labath, committed by ).
Herald added a subscriber: llvm-commits.
Repository:
rL LLVM
https://reviews.llvm.org/D48215
Files:
lldb/trunk/incl
labath created this revision.
labath added reviewers: zturner, jingham, clayborg.
Herald added a subscriber: mgorny.
The dump function was the only part of this class which depended on
high-level functionality. This was due to the DumpDataExtractor
function, which uses info from a running target t
Author: labath
Date: Wed Jun 20 02:00:30 2018
New Revision: 335106
URL: http://llvm.org/viewvc/llvm-project?rev=335106&view=rev
Log:
Fix windows build broken by r335104
lldb-python.h needs to be included first to work around some
incompatibilities between windows and python headers.
Modified:
Author: labath
Date: Wed Jun 20 02:53:30 2018
New Revision: 335112
URL: http://llvm.org/viewvc/llvm-project?rev=335112&view=rev
Log:
Fix compilation with mingw-w64 (pr37873)
Modified:
lldb/trunk/include/lldb/lldb-defines.h
Modified: lldb/trunk/include/lldb/lldb-defines.h
URL:
http://llvm.or
Author: labath
Date: Wed Jun 20 03:45:29 2018
New Revision: 335114
URL: http://llvm.org/viewvc/llvm-project?rev=335114&view=rev
Log:
IRInterpreter: fix sign extension of small types (pr37840)
Sign-extension of small types (e.g. short) was not handled correctly.
The reason for that was that when w
apolyakov updated this revision to Diff 152069.
apolyakov added a comment.
Changed method's name from `ReturnMIStatus` to `HandleSBError`. Also added one
more use case(see -exec-step's Execute function).
The only thing that worries me is that if we want to specify handler for error
case, we sho
apolyakov added a comment.
Just reminder that it still needs a review. Thanks in advance.
https://reviews.llvm.org/D47991
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: labath
Date: Wed Jun 20 07:54:34 2018
New Revision: 335132
URL: http://llvm.org/viewvc/llvm-project?rev=335132&view=rev
Log:
Make sure TestNumThreads works with libc++
The problem was that with libc++ the std::unique_lock declaration was
completely inlined, so there was no line table entr
aprantl added a comment.
In https://reviews.llvm.org/D48295#1137595, @apolyakov wrote:
> Changed method's name from `ReturnMIStatus` to `HandleSBError`. Also added
> one more use case(see -exec-step's Execute function).
>
> The only thing that worries me is that if we want to specify handler for
aprantl added a comment.
This patch is adding new overloads to SBAPI calls that don't return an SBError,
such as:
// Old:
void StepOutOfFrame(SBFrame &frame);
// New:
void StepOutOfFrame(SBFrame &frame, SBError &error);
I wonder if it would be easier to use and more consistent with the
Author: labath
Date: Wed Jun 20 10:32:48 2018
New Revision: 335149
URL: http://llvm.org/viewvc/llvm-project?rev=335149&view=rev
Log:
Make test sources compatible with android+libcxx+modules
In a modules build, android is very picky about which symbols are
visible after including libc++ headers (e
The SB API's tend to take SBError as an in/out parameter for the cases where
the function in question naturally returns some other value, and return an
SBError when there's no other logical return value.
So in these cases it would be more in line with the general practice to return
an SBError.
jingham added a comment.
The SB API's tend to take SBError as an in/out parameter for the cases where
the function in question naturally returns some other value, and return an
SBError when there's no other logical return value.
So in these cases it would be more in line with the general practi
apolyakov added a comment.
I think we just can make old versions of API methods returning SBError in all
cases. This way we'll deal with SBError and won't break down API calls.
For example:
// old
void StepOver() {
...
}
// new
SBError StepOver() {
...
return sb_error;
aprantl accepted this revision.
aprantl added a comment.
Okay.. then let's go with this version.
https://reviews.llvm.org/D47991
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jingham added a comment.
Won't this break client code that was calling StepOver? We are pretty serious
about maintaining binary compatibility with the SB API's.
Jim
https://reviews.llvm.org/D47991
___
lldb-commits mailing list
lldb-commits@lists.
Won't this break client code that was calling StepOver? We are pretty serious
about maintaining binary compatibility with the SB API's.
Jim
> On Jun 20, 2018, at 11:19 AM, Alexander Polyakov via Phabricator
> wrote:
>
> apolyakov added a comment.
>
> I think we just can make old versions o
aprantl added a comment.
In https://reviews.llvm.org/D47991#1138029, @jingham wrote:
> Won't this break client code that was calling StepOver? We are pretty
> serious about maintaining binary compatibility with the SB API's.
Yeah, we can't replace existing function calls: The C++ name manglin
apolyakov added a comment.
If some client uses `StepOver` like `sbThread.StepOver()`, then making
`StepOver` return SBError won't break anything since in this case returned
SBError value will just be ignored. Am I missing something?
https://reviews.llvm.org/D47991
__
The client won't be expecting a struct return, and will have generated code to
take a void return. If SBError happens to be returned in registers, nothing
bad will happen, but if it's returned on the stack, that would corrupt the
caller's stack. Relying on the particular kind of struct return
jingham added a comment.
The client won't be expecting a struct return, and will have generated code to
take a void return. If SBError happens to be returned in registers, nothing
bad will happen, but if it's returned on the stack, that would corrupt the
caller's stack. Relying on the particu
apolyakov added a comment.
In https://reviews.llvm.org/D47991#1138071, @jingham wrote:
> The client won't be expecting a struct return, and will have generated code
> to take a void return. If SBError happens to be returned in registers,
> nothing bad will happen, but if it's returned on the s
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
That seems fine to me.
https://reviews.llvm.org/D47991
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/
Author: labath
Date: Wed Jun 20 13:13:04 2018
New Revision: 335163
URL: http://llvm.org/viewvc/llvm-project?rev=335163&view=rev
Log:
Remove some instances of manual UUID pretty-printing
Identical functionality is already offered by the UUID::getAsString
method.
Modified:
lldb/trunk/source/P
friss created this revision.
friss added reviewers: clayborg, labath, jingham.
Herald added subscribers: JDevlieghere, aprantl.
Debug information is read lazily so a lot of the state of the reader
is constructred incrementally. There's also nothing preventing symbol
queries to be performed at the
apolyakov added a comment.
With such overloads we'll get compile time error. If we have overload:
bool HandleSBError(SBError error, std::function successHandler = []
{some func}, std::function errorHandler = [] {some func});
bool HandleSBError(SBError error, std::function errorHandler);
and
apolyakov added a comment.
By the way, I do not see a solution better than current patch, but, at the same
time, I do not like current patch. Maybe we should discard this idea?
https://reviews.llvm.org/D48295
___
lldb-commits mailing list
lldb-comm
zturner added a comment.
Long term I think one potentially interesting possibility for solving a lot of
these threading and lazy evaluation issues is to make a task queue that runs
all related operations on a single thread and returns a future you can wait on.
This way, the core data structure
Author: apolyakov
Date: Wed Jun 20 14:43:16 2018
New Revision: 335180
URL: http://llvm.org/viewvc/llvm-project?rev=335180&view=rev
Log:
Improve SBThread's stepping API using SBError parameter.
Summary: The new methods will allow to get error messages from stepping API.
Reviewers: aprantl, claybo
This revision was automatically updated to reflect the committed changes.
Closed by commit rL335180: Improve SBThread's stepping API using SBError
parameter. (authored by apolyakov, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D47991
friss added a comment.
In https://reviews.llvm.org/D48393#1138398, @zturner wrote:
> Long term I think one potentially interesting possibility for solving a lot
> of these threading and lazy evaluation issues is to make a task queue that
> runs all related operations on a single thread and retu
> On Jun 20, 2018, at 3:14 PM, Frederic Riss via Phabricator
> wrote:
>
> friss added a comment.
>
> In https://reviews.llvm.org/D48393#1138398, @zturner wrote:
>
>> Long term I think one potentially interesting possibility for solving a lot
>> of these threading and lazy evaluation issues
aprantl added a comment.
I guess you *could* use different function names, such as HandleSBError,
HandleSBErrorWithSuccess, HandleSBErrorWithSuccessAndFailure, ...
https://reviews.llvm.org/D48295
___
lldb-commits mailing list
lldb-commits@lists.ll
35 matches
Mail list logo
