xiaobai added a comment.
Over the weekend I dug into this further. It looks like the environment I found
this bug in didn't have C++11 support and was using `std::string::length()`,
which tries to perform a memory read where it's not supposed to, resulting in a
segfault.
On my friend's Ubuntu s
xiangzhai created this revision.
Hi LLVM developers,
Resurrect pselect MainLoop implementation https://reviews.llvm.org/D32600
commited by Pavel, then it failed to build for Linux:
/data/project/LLVM/llvm/tools/lldb/source/Host/common/MainLoop.cpp:158:10:
error: no viable conversion from ret
vbalu updated this revision to Diff 97569.
vbalu added a comment.
Herald added a subscriber: srhines.
Added the test case.
Repository:
rL LLVM
https://reviews.llvm.org/D32732
Files:
packages/Python/lldbsuite/test/functionalities/target_command/TestTargetCommand.py
packages/Python/lldbsu
This doesn't make things any worse, but a better solution would be to
figure out why cmake has not detected ppoll(2) support, as lldb on
linux is useless without the signal polling stuff. If your system does
have ppoll, but we're not detecting it, we will have to fix detection
code. On the off chan
On 3 May 2017 at 07:41, vignesh balu wrote:
> you mean like this "exe = os.path.join('./newdir/','proc_attach')". I can't
probably something like: os.path.join('.', 'newdir', 'proc_attach')
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http:
labath added a comment.
It's definitely still a bug worth fixing, we cannot rely on undefined behavior
like that.
Thank you very much for adding the test case. Looking at the test suite again,
I think I've found a better place for the test. Could you put the test in
test/testcases/expression_c
It seems xiangzhai has already "cranked up a review" :) (D32787), so
moving the discussion there.
On 3 May 2017 at 09:57, Pavel Labath wrote:
> This doesn't make things any worse, but a better solution would be to
> figure out why cmake has not detected ppoll(2) support, as lldb on
> linux is use
labath requested changes to this revision.
labath added a subscriber: probinson.
labath added a comment.
This revision now requires changes to proceed.
This will not compile on windows, which really is the only branch we expected
to have `SIGNAL_POLLING_UNSUPPORTED` set. In this sense Pauls (cc'e
vbalu updated this revision to Diff 97575.
vbalu marked an inline comment as done.
vbalu added a comment.
modified exe path computation
Repository:
rL LLVM
https://reviews.llvm.org/D32522
Files:
packages/Python/lldbsuite/test/functionalities/process_attach/TestProcessAttach.py
Index:
p
xiangzhai added a comment.
Hi Pavel,
> Could one of you guys check whether you really don't have the ppoll syscall
> (for example, are able to compile a simple program using ppoll (*))
It has! clang is able to compile the simple program!
> If you do, then I may need a bit more help to debug th
labath added a comment.
In https://reviews.llvm.org/D32787#744379, @xiangzhai wrote:
> Hi Pavel,
>
> > Could one of you guys check whether you really don't have the ppoll syscall
> > (for example, are able to compile a simple program using ppoll (*))
>
> It has! clang is able to compile the simp
Author: labath
Date: Wed May 3 05:00:00 2017
New Revision: 302008
URL: http://llvm.org/viewvc/llvm-project?rev=302008&view=rev
Log:
Check for lack of C++ context first when demangling
Summary: It seems that if we have no context, then it can't possibly be a
method. Check that first.
Reviewers
tberghammer added a comment.
Personally I never really liked TaskRunner (even though I was the one
implemented it) because I think it adds a lot of extra complexity for fairly
little gain and thinking about it a bit more I think in most use case a more
targeted solution at the call site will pr
Author: labath
Date: Wed May 3 06:27:35 2017
New Revision: 302013
URL: http://llvm.org/viewvc/llvm-project?rev=302013&view=rev
Log:
Windows fix for TestConflictingDefinition makefile
gnuwin32 rm does not like wildcards that match nothing even if we
specify -f (probably because the wildcard expan
clayborg accepted this revision.
clayborg added a comment.
-glldb doesn't emit the Apple accelerator tables IIRC. We don't need to change
the DWARF, but just add the Apple accelerator tables by modifying clang to emit
them. They will be just fine with DWO as each DWO file would have a set of
th
Author: fjricci
Date: Wed May 3 10:00:04 2017
New Revision: 302027
URL: http://llvm.org/viewvc/llvm-project?rev=302027&view=rev
Log:
Don't attempt to use mpx registers on unsupported platforms
Summary:
The existing cpp-level checks using PR_MPX_ENABLE_MANAGEMENT aren't sufficient,
as this isn't
This revision was automatically updated to reflect the committed changes.
Closed by commit rL302027: Don't attempt to use mpx registers on unsupported
platforms (authored by fjricci).
Changed prior to commit:
https://reviews.llvm.org/D32719?vs=97447&id=97648#toc
Repository:
rL LLVM
https://
kubamracek added a comment.
This revision now requires changes to proceed.
ping
https://reviews.llvm.org/D30007
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath created this revision.
Herald added subscribers: srhines, rengolin, aemerson.
Arm64 Procedure Call Standard specifies than only vectors up to 16 bytes
are stored in v0 (which makes sense, as that's the size of the
register). 32-byte vector types are passed as regular structs via x8
pointer.
probinson added a comment.
Looking at CMakeError.log, the test program does `#include ` but does
not `#define _GNU_SOURCE`. The define has to be there for your example to
compile on my Ubuntu.
Repository:
rL LLVM
https://reviews.llvm.org/D32787
__
clayborg accepted this revision.
clayborg added a comment.
Looks fine to me, make sure Jim is happy as well.
https://reviews.llvm.org/D30007
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lld
jingham added a reviewer: jingham.
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.
I actually think the behavior you are seeing is the designed behavior, but it
isn't clearly documented.
Target variable is designed to help manag
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
Sorry for the delay. That's fine.
https://reviews.llvm.org/D30007
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.
scott.smith updated this revision to Diff 97695.
scott.smith added a comment.
update to use a private llvm::ThreadPool. I chose this over a 2nd global
"TaskPool" because if the threads are going to be short lived, there isn't much
point in having a global pool rather than a short-lived instanti
labath added a comment.
In https://reviews.llvm.org/D32787#744974, @probinson wrote:
> Looking at CMakeError.log, the test program does `#include ` but does
> not `#define _GNU_SOURCE`. The define has to be there for your example to
> compile on my Ubuntu.
We do that in LLDBGenerateConfig.cm
scott.smith created this revision.
Use TaskMapOverInt to demangle the symbols in parallel. Defer categorization
of C++ symbols until later, when it can be determined what contexts are
definitely classes, and what might not be.
Repository:
rL LLVM
https://reviews.llvm.org/D32820
Files:
i
scott.smith added a comment.
This commit uses TaskMapOverInt from change https://reviews.llvm.org/D32757,
which hasn't landed yet.
Repository:
rL LLVM
https://reviews.llvm.org/D32820
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http
probinson added a comment.
In https://reviews.llvm.org/D32787#745099, @labath wrote:
> Could it be that you just have stale cmake cache?
That could easily be true. Rerunning cmake didn't fix it; short of deleting
the entire build directory, is there a way to refresh the cache?
Repository:
zturner requested changes to this revision.
zturner added inline comments.
This revision now requires changes to proceed.
Comment at:
source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp:530-560
+ struct loader {
+DYLDRendezvous::iterator I;
+ModuleSP m;
+
zturner added inline comments.
Comment at:
source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp:530-560
+ struct loader {
+DYLDRendezvous::iterator I;
+ModuleSP m;
+std::shared_future f;
+ };
+ std::vector loaders(num_to_load);
+ llvm::ThreadPool lo
scott.smith created this revision.
The Timer destructor would grab a global mutex in order to update execution
time. Add a class to define a category once, statically; the class adds itself
to an atomic singly linked list, and thus subsequent updates only need to use
an atomic rather than grab
scott.smith added inline comments.
Comment at:
source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp:530-560
+ struct loader {
+DYLDRendezvous::iterator I;
+ModuleSP m;
+std::shared_future f;
+ };
+ std::vector loaders(num_to_load);
+ llvm::ThreadPoo
zturner added inline comments.
Comment at:
source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp:530-560
+ struct loader {
+DYLDRendezvous::iterator I;
+ModuleSP m;
+std::shared_future f;
+ };
+ std::vector loaders(num_to_load);
+ llvm::ThreadPool lo
labath added a comment.
In https://reviews.llvm.org/D32787#745139, @probinson wrote:
> In https://reviews.llvm.org/D32787#745099, @labath wrote:
>
> > Could it be that you just have stale cmake cache?
>
>
> That could easily be true. Rerunning cmake didn't fix it; short of deleting
> the entire
xiaobai updated this revision to Diff 97717.
xiaobai added a comment.
Moving test per @labath's suggestion
https://reviews.llvm.org/D32421
Files:
packages/Python/lldbsuite/test/expression_command/multiline/TestMultilineExpressions.py
source/Host/common/Editline.cpp
Index: source/Host/com
zturner added a comment.
https://reviews.llvm.org/D32826
Repository:
rL LLVM
https://reviews.llvm.org/D32597
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
probinson added a comment.
In https://reviews.llvm.org/D32787#745205, @labath wrote:
> In https://reviews.llvm.org/D32787#745139, @probinson wrote:
>
> > In https://reviews.llvm.org/D32787#745099, @labath wrote:
> >
> > > Could it be that you just have stale cmake cache?
> >
> >
> > That could ea
scott.smith created this revision.
Utilize atomics to update linked lists without requiring locks. Reduces the
number of calls to compute the hash by not having to compute it once to
determine the bucket and then again inside a separate hashtable implementation.
Use xxhash for better performa
scott.smith added a comment.
Note, I don't expect you guys to want this as is, since the # of buckets can't
grow, and thus for very large applications this will behave O(n) instead of
O(1). Before I bother to convert this to 1M skip lists (instead of 1M singly
linked lists), is this something
clayborg added a comment.
Do you have performance numbers here? I am all for it if it improves
performance. If this is faster than llvm::StringMap why not just fix it there?
Seems like everyone could benefit if you fix it in LLVM?
Repository:
rL LLVM
https://reviews.llvm.org/D32832
_
clayborg added a comment.
Sorry missed your first note about perf. This has to be able to handle any
number of strings efficiently and growing buckets is probably needed. How many
buckets are you starting with here? The design probably shouldn't take up gobs
of memory if it just has a few strin
It isn't uncommon for folks to debug programs with all the debug information
for the whole system available. In those cases, what looks to the user like a
normal sized application is actually a very large one as far as lldb's global
string pool is concerned. My experience is that whenever you
scott.smith added a comment.
In https://reviews.llvm.org/D32832#745361, @clayborg wrote:
> Do you have performance numbers here? I am all for it if it improves
> performance. If this is faster than llvm::StringMap why not just fix it
> there? Seems like everyone could benefit if you fix it in L
Hello everyone,
Below are some buildbot numbers for the week of 04/16/2017 - 04/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
Hello everyone,
Below are some buildbot numbers for the last week of 04/23/2017 -
04/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 fro
xiangzhai abandoned this revision.
xiangzhai added a comment.
> Opening the CMakeCache.txt, and deleting the HAVE_PPOLL line should
> re-trigger the detection
Fixed!
Repository:
rL LLVM
https://reviews.llvm.org/D32787
___
lldb-commits mailing l
eugene accepted this revision.
eugene added inline comments.
This revision is now accepted and ready to land.
Comment at: source/Host/common/MainLoop.cpp:66
class MainLoop::RunImpl {
public:
Could you please add here a comment describing when kqueue/pselect/
vbalu added a comment.
i am confused as I dont see it is similar way when i don't print global
variable before strting inferior.
For the c file "lldbsuite/test/functionalities/target_command/globals.c" i see
"target variable" behaves differently as below.
**Without printing global variable be
48 matches
Mail list logo
