On 22 September 2016 at 01:00, Greg Clayton via lldb-commits
wrote:
> If you use a StringRef in printf, please use "%*s" and then put the count and
> data pointer into the printf, so the above line would become:
>
> + s->Printf("source regex = \"%*s\", exact_match = %d",
> +(int)m_re
+1. One of the points I outlined on my list was to use llvm streams. So
that also solves the problem
On Thu, Sep 22, 2016 at 4:54 AM Pavel Labath wrote:
> On 22 September 2016 at 01:00, Greg Clayton via lldb-commits
> wrote:
> > If you use a StringRef in printf, please use "%*s" and then put the
labath accepted this revision.
Comment at:
source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp:513-521
@@ -513,1 +512,11 @@
+
+ // Find out how many bytes we need to watch after 4-byte alignment boundary.
+ uint8_t watch_size = (addr & 0x03) + size;
+
+ // We canno
Author: labath
Date: Thu Sep 22 10:26:43 2016
New Revision: 282167
URL: http://llvm.org/viewvc/llvm-project?rev=282167&view=rev
Log:
Fix TestBreakpointSerialization on windows
The test exposed a bug in the StructuredData Serialization code, which did not
escape the backslash properly. This manife
Author: tfiala
Date: Thu Sep 22 11:00:01 2016
New Revision: 282171
URL: http://llvm.org/viewvc/llvm-project?rev=282171&view=rev
Log:
added environment variable-related Args gtests
Also fixed up a couple misbehaving functions. It is perfectly
legal to have env vars with no values (i.e. the '=' an
Thanks for the test. Is there any practical difference between "ARGS=" and
"ARGS"?
On Thu, Sep 22, 2016 at 9:08 AM Todd Fiala via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: tfiala
> Date: Thu Sep 22 11:00:01 2016
> New Revision: 282171
>
> URL: http://llvm.org/viewvc/llvm-proje
yea I mostly just wanted to know if we needed to specificlaly distinguish
between ARG=\0 and ARG\0. Because if so the second parameter would need to
be Optional since StringRef has no way to differentiate between
"I don't refer to anything" versus "I refer to the empty string".
(Technically it ki
Primarily because we pass them verbatim to posix_spawn and other launchers,
and there it is legitimate to not have an equal with trailing nothingness.
On the Xcode side, we use a ton of environment variables.
As to whether there is a difference between ARG1=\0 and ARG1\0, I'm not
sure.
On Thu, Se
Author: tfiala
Date: Thu Sep 22 11:29:48 2016
New Revision: 282172
URL: http://llvm.org/viewvc/llvm-project?rev=282172&view=rev
Log:
fix DarwinLog no-info/no-debug case
This started failing recently:
TestDarwinLogSourceDebug.py
It looks like the behavior of specifying the OS_ACTIVITY_MODE
env va
Okay. Yeah I don't see us needing to support the equal with trailing nothing.
-Todd
> On Sep 22, 2016, at 9:23 AM, Zachary Turner wrote:
>
> yea I mostly just wanted to know if we needed to specificlaly distinguish
> between ARG=\0 and ARG\0. Because if so the second parameter would need to
johanengelen created this revision.
johanengelen added a reviewer: LLDB.
johanengelen added a subscriber: lldb-commits.
Binaries with Dwarf language set to "DW_LANG_D" currently do not show much
information in LLDB (e.g. no local variables).
With this simple change, Clang language support is use
Author: enrico
Date: Thu Sep 22 12:47:33 2016
New Revision: 282178
URL: http://llvm.org/viewvc/llvm-project?rev=282178&view=rev
Log:
The host version of lldb always builds for macosx
Modified:
lldb/trunk/scripts/Xcode/lldbbuild.py
Modified: lldb/trunk/scripts/Xcode/lldbbuild.py
URL:
http:/
Author: enrico
Date: Thu Sep 22 12:59:58 2016
New Revision: 282179
URL: http://llvm.org/viewvc/llvm-project?rev=282179&view=rev
Log:
Actually, do it this way because I will want to know if I am in a host build
elsewhere too
Modified:
lldb/trunk/scripts/Xcode/lldbbuild.py
Modified: lldb/tru
Author: zturner
Date: Thu Sep 22 16:06:13 2016
New Revision: 282195
URL: http://llvm.org/viewvc/llvm-project?rev=282195&view=rev
Log:
Try to fix build errors on Android.
It doesn't like the implicit conversion from T[] to ArrayRef
so I'm using `llvm::makeArrayRef()`. Hopefully I got everything.
Author: cbieneman
Date: Thu Sep 22 16:08:27 2016
New Revision: 282196
URL: http://llvm.org/viewvc/llvm-project?rev=282196&view=rev
Log:
[CMake] Fixing a small hack in add_lldb_library
This code was adding an explicit dependency on libclang because lldb needs
clang headers, changing this to inste
At the end of the day though, lldb DOES need to link against libclang. Is
it still doing this?
On Thu, Sep 22, 2016 at 2:17 PM Chris Bieneman via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: cbieneman
> Date: Thu Sep 22 16:08:27 2016
> New Revision: 282196
>
> URL: http://llvm.o
Calls to add_dependencies don’t setup linkage, they just setup build order, so
changing this has no impact on what is linked or how.
-Chris
> On Sep 22, 2016, at 2:21 PM, Zachary Turner wrote:
>
> At the end of the day though, lldb DOES need to link against libclang. Is it
> still doing this
Ok, cool!
On Thu, Sep 22, 2016 at 2:23 PM Chris Bieneman wrote:
> Calls to add_dependencies don’t setup linkage, they just setup build
> order, so changing this has no impact on what is linked or how.
>
> -Chris
>
> On Sep 22, 2016, at 2:21 PM, Zachary Turner wrote:
>
> At the end of the day th
Also of note. This implementation is “standalone” safe. If LLDB is being built
without clang (against a pre-installed clang) CLANG_TABLEGEN_TARGETS will not
be set, so no dependency will be setup.
That same concern came up in a similar patch I submitted to Swift.
-Chris
> On Sep 22, 2016, at 2
beanz created this revision.
beanz added reviewers: tfiala, zturner.
beanz added a subscriber: lldb-commits.
Herald added subscribers: mgorny, beanz.
This alters the generation of LLDB_REVISION to be heavily based on how clang
generates its version header. There are two benefits of this aproach.
zturner created this revision.
zturner added a reviewer: clayborg.
zturner added a subscriber: lldb-commits.
As before, some copies are removed, a few are introduced. When I get to
Option::SetValue, those that are introduced should go away.
https://reviews.llvm.org/D24847
Files:
include/lldb
zturner added a comment.
Should this be sunk into a common llvm function instead of copying from clang?
I don't have a strong opinion, but are you one of the main CMake maintainers in
LLVM, so whatever you think is best.
https://reviews.llvm.org/D24846
_
Author: jingham
Date: Thu Sep 22 17:00:59 2016
New Revision: 282205
URL: http://llvm.org/viewvc/llvm-project?rev=282205&view=rev
Log:
Serilize the thread options within the breakpoint options.
Modified:
lldb/trunk/include/lldb/Breakpoint/BreakpointOptions.h
lldb/trunk/include/lldb/Target/
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
We could avoid many of the copies in the printf statements by by doing
something like this in a common header file:
#define LLVM_STRINGREF_PRINTF_FORMAT "%*s"
#define LLVM_S
clayborg added a comment.
I am not saying we have to do the printf changes, I was just seeing what you
think. I would like to see the StringRef variants of functions put in as part
of this.
https://reviews.llvm.org/D24847
___
lldb-commits mailing
Author: jingham
Date: Thu Sep 22 17:20:28 2016
New Revision: 282207
URL: http://llvm.org/viewvc/llvm-project?rev=282207&view=rev
Log:
Add the ability to deserialize only breakpoints matching a given name.
Also tests for this and the ThreadSpec serialization.
Modified:
lldb/trunk/include/lldb
OptionValueString is actually the next item on my list. I tried it before
this and it was a very big CL, But maybe with this done it will be smaller.
I can try again but if the cl grows too large i think it's better to do it
in a followup. If nothing else so that if a buildbot fails it's easier to
I'll try the 2 additional string ref changes first and see how bad it is
On Thu, Sep 22, 2016 at 3:36 PM Zachary Turner wrote:
> OptionValueString is actually the next item on my list. I tried it before
> this and it was a very big CL, But maybe with this done it will be smaller.
>
> I can try ag
clayborg added a comment.
Yeah, don't do any calls that don't need to be converted. Just the ones you
need. Should just add 2 StringRef variant functions. Don't feel the need to
completely fix OptionValueString or OptionValueUInt64. We can do the full
change over in a future CL. See if you can
clayborg added a comment.
no printf fixes are fine. I don't mind if error cases have str().c_str() so
much.
https://reviews.llvm.org/D24847
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lld
I took a quick glance, now I remember. It uses a validator, so the
validator has to either update its signature or make a copy. It's also
called by SetValueFromCString, so that has to be updated or make a copy.
Then it spirals out from there.
So yea, the copy is still going to be there, just in a
clayborg added a comment.
You can still leave the "const char *" versions in there for now until you get
to the cleanup. No spiral if you do that.
https://reviews.llvm.org/D24847
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://list
Ok that's fine then
On Thu, Sep 22, 2016 at 3:59 PM Greg Clayton wrote:
> clayborg added a comment.
>
> You can still leave the "const char *" versions in there for now until you
> get to the cleanup. No spiral if you do that.
>
>
> https://reviews.llvm.org/D24847
>
>
>
>
tfiala created this revision.
tfiala added reviewers: clayborg, labath.
tfiala added a subscriber: lldb-commits.
This change introduces the concept of a platform-specific, pre-kill-hook
mechanism. If a platform defines the hook, then the hook gets called right
after a timeout is detected in a t
tfiala added inline comments.
Comment at: packages/Python/lldbsuite/test/dosep.py:238-245
@@ +237,10 @@
+# runner for our platform.
+module_name = "lldbsuite.pre_kill_hook." + platform.system().lower()
+try:
+import importlib
+module
tfiala added a comment.
Greg also had the idea of having a fallback mechanism that uses a newly-spun-up
lldb to attach to the to-be-killed process, and retrieves the threads and
backdtraces, to dump out a compact description. That's nice in that it should
work on any host that has a working ll
beanz added a comment.
Putting this in LLVM would be ideal, but I think doing that requires a larger
refactoring of how LLVM and Clang handle SCM versions. I was kinda hoping to
land this and fix the lldb support, but if you'd prefer I can shelve this until
after fixing LLVM & Clang.
https://
If it's non trivial then then can go in first, that's fine. I'm ooo for the
rest of the day, so let me test it out on Windows first
On Thu, Sep 22, 2016 at 4:36 PM Chris Bieneman wrote:
> beanz added a comment.
>
> Putting this in LLVM would be ideal, but I think doing that requires a
> larger re
Author: jingham
Date: Thu Sep 22 18:42:42 2016
New Revision: 282212
URL: http://llvm.org/viewvc/llvm-project?rev=282212&view=rev
Log:
Add the ability to append breakpoints to the save file.
Modified:
lldb/trunk/include/lldb/API/SBTarget.h
lldb/trunk/include/lldb/Target/Target.h
lldb/
andrewford created this revision.
andrewford added a reviewer: jingham.
andrewford added a subscriber: lldb-commits.
Change-Id: I611460cf4df58073bda64e16847e5358c3361aa7
https://reviews.llvm.org/D24853
Files:
include/lldb/Breakpoint/BreakpointOptions.h
Index: include/lldb/Breakpoint/Breakpoin
andrewford added a comment.
BTW, I don't have commit access, would appreciate if someone could submit for
me assuming this is acceptable :)
https://reviews.llvm.org/D24853
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.
Eugene.Zelenko added a subscriber: Eugene.Zelenko.
Eugene.Zelenko added a comment.
Looks like patch was part of r272301.
Repository:
rL LLVM
https://reviews.llvm.org/D21152
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.ll
Eugene.Zelenko added a subscriber: Eugene.Zelenko.
Eugene.Zelenko added a comment.
Appear to be reverted in r272062.
Repository:
rL LLVM
https://reviews.llvm.org/D21032
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.o
Author: zturner
Date: Thu Sep 22 21:54:26 2016
New Revision: 282226
URL: http://llvm.org/viewvc/llvm-project?rev=282226&view=rev
Log:
Fix windows build caused by mixing enum and enum class.
Modified:
lldb/trunk/include/lldb/Breakpoint/BreakpointOptions.h
lldb/trunk/include/lldb/Target/Thr
Fixed in r282226, thanks for the tip.
On Thu, Sep 22, 2016 at 5:15 PM Andrew Ford via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> andrewford added a comment.
>
> BTW, I don't have commit access, would appreciate if someone could submit
> for me assuming this is acceptable :)
>
>
> https:
zturner updated this revision to Diff 72234.
zturner added a comment.
Updated the two requested functions. I still had to make a few more changes to
catch the implicit conversions into each of these functions, but it wasn't too
bad.
https://reviews.llvm.org/D24847
Files:
include/lldb/Inter
tfiala accepted this revision.
tfiala added a comment.
This revision is now accepted and ready to land.
Looks good.
I think it's fine landing here for now based on your earlier comments about the
refactoring effort to get it into LLVM/clang. I do think it's worth trying to
sink it lower when t
47 matches
Mail list logo
