zturner added a subscriber: zturner.
zturner added a comment.
Don't use an environment variable, add a command line flag to the script
instead
http://reviews.llvm.org/D19067
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm
Don't use an environment variable, add a command line flag to the script
instead
On Fri, Apr 15, 2016 at 3:27 PM Francis Ricci wrote:
> fjricci added a comment.
>
> So I looked at `finishSwigPythonLLDB.py`, and it does look like that's
> where the bug is. This script sets the end of the symlink p
fjricci added a comment.
So I looked at `finishSwigPythonLLDB.py`, and it does look like that's where
the bug is. This script sets the end of the symlink path with:
strSrc = os.path.join("lib", "liblldb" + strLibFileExtn)
Note here that "lib" is hardcoded, and doesn't use the `LLVM_LIBDIR_SUF
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
I am OK with this, but Jason Molenda needs to be OK as well. Seems like we
should have a function on the right object that would return the PC that we
should use when looking up symbols fo
uweigand added reviewers: clayborg, tberghammer.
uweigand updated this revision to Diff 53951.
uweigand added a comment.
Add fix for a related problem that still caused unwind failures on SystemZ.
The ResolveSymbolContextForAddress sometimes returns a "symbol" with empty
name. This turns out to
Hello everyone,
Below are some buildbot numbers for the last week of 4/03/2016 - 4/09/2016.
Thanks
Galina
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green):
buildername
zturner added a comment.
I wrote a library in llvm which is independent of the Windows system dll
and is abstracted such that we can plug in a non Windows specific version
of a pdb parser once we understand the format well enough.
For now, if you're not on Windows this library will just return an
I wrote a library in llvm which is independent of the Windows system dll
and is abstracted such that we can plug in a non Windows specific version
of a pdb parser once we understand the format well enough.
For now, if you're not on Windows this library will just return an error if
you try to creat
clayborg added a comment.
Shouldn't the SymbolFilePDB be only enabled in windows since it is useless on
any other system since you are using the Windows system DLL to parse the info?
http://reviews.llvm.org/D18848
___
lldb-commits mailing list
lldb
This revision was automatically updated to reflect the committed changes.
Closed by commit rL266423: Work around a linux libc bug causing a crash in
TaskPool (authored by labath).
Changed prior to commit:
http://reviews.llvm.org/D19153?vs=53865&id=53869#toc
Repository:
rL LLVM
http://review
Author: labath
Date: Fri Apr 15 05:49:07 2016
New Revision: 266423
URL: http://llvm.org/viewvc/llvm-project?rev=266423&view=rev
Log:
Work around a linux libc bug causing a crash in TaskPool
Summary:
Doing a pthread_detach while the thread is exiting can cause crashes or other
mischief, so we
mak
tberghammer accepted this revision.
tberghammer added a comment.
This revision is now accepted and ready to land.
Looks good
http://reviews.llvm.org/D19153
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailm
Author: uweigand
Date: Fri Apr 15 04:55:52 2016
New Revision: 266422
URL: http://llvm.org/viewvc/llvm-project?rev=266422&view=rev
Log:
Fix usage of APInt.getRawData for big-endian systems
Recommit modified version of r266311 including build bot regression fix.
This differs from the original r266
labath created this revision.
labath added a reviewer: tberghammer.
labath added a subscriber: lldb-commits.
Doing a pthread_detach while the thread is exiting can cause crashes or other
mischief, so we
make sure the thread stays around long enough. The performance impact of the
added
synchroniz
Pavel Labath wrote on 15.04.2016 11:19:35:
> Thanks a lot for cleaning that up. I hope you'll be able to find the
> cause of the 32-bit problems quickly. If you need help reproducing the
> errors, I can send you some of the detailed logs from our buildbots.
I did manage to find the cause of the
Author: uweigand
Date: Fri Apr 15 04:15:47 2016
New Revision: 266420
URL: http://llvm.org/viewvc/llvm-project?rev=266420&view=rev
Log:
Make Scalar::SChar return an explicit signed type
This is needed for platforms where the default "char" type is unsigned.
Originally committed as part of (now re
Author: uweigand
Date: Fri Apr 15 04:14:59 2016
New Revision: 266418
URL: http://llvm.org/viewvc/llvm-project?rev=266418&view=rev
Log:
Fix Scalar::SetValueFromData for 128- and 256-bit types
Obvious fix for incorrect use of GetU64 offset pointer.
Originally committed as part of (now reverted) r2
Author: uweigand
Date: Fri Apr 15 04:15:22 2016
New Revision: 266419
URL: http://llvm.org/viewvc/llvm-project?rev=266419&view=rev
Log:
Fix Scalar::MakeSigned for 128- and 256-bit types.
Obvious fix for incorrect result types of the operation.
Originally committed as part of (now reverted) r26631
Author: uweigand
Date: Fri Apr 15 04:14:32 2016
New Revision: 266417
URL: http://llvm.org/viewvc/llvm-project?rev=266417&view=rev
Log:
Fix ABISysV_s390x::GetArgumentValues
This routine contained a stray "return false;" making part of the code
never executed. Also, the stack offset where to find
Thanks a lot for cleaning that up. I hope you'll be able to find the
cause of the 32-bit problems quickly. If you need help reproducing the
errors, I can send you some of the detailed logs from our buildbots.
cheers,
pl
On 14 April 2016 at 22:25, Ulrich Weigand wrote:
> Ulrich Weigand/Germany/IB
This revision was automatically updated to reflect the committed changes.
Closed by commit rL266416: Make destructor breakpoint location test more
resilient (authored by labath).
Changed prior to commit:
http://reviews.llvm.org/D19052?vs=53694&id=53860#toc
Repository:
rL LLVM
http://reviews
Author: labath
Date: Fri Apr 15 04:11:22 2016
New Revision: 266416
URL: http://llvm.org/viewvc/llvm-project?rev=266416&view=rev
Log:
Make destructor breakpoint location test more resilient
Summary:
The original breakpoint location test was failing for linux, because the
compilers here tend to
me
labath added a comment.
In http://reviews.llvm.org/D19067#401416, @fjricci wrote:
> When I use LLVM_LIBDIR_SUFFIX=64, it looks like the python _lldb.so symlink
> still points to build/lib/liblldb.so, instead of using the lib64 directory.
> So if I do this, none of the tests will run on the chec
23 matches
Mail list logo
