looks good! Feel free to commit whenever, I'd definitely recommend posting
a PSA on cfe-dev@ (after you commit) so that people know about it. You
might also get some useful ideas for improvements that way too.
On Thu, Oct 26, 2017 at 9:52 PM Don Hinton wrote:
> On Thu, Oct 26, 2017 at 5:44 PM,
Author: labath
Date: Thu Oct 26 21:53:24 2017
New Revision: 316740
URL: http://llvm.org/viewvc/llvm-project?rev=316740&view=rev
Log:
Fix a use-after-free in lldb-server
UriParser::Parse is returning a StringRef pointing the the parsed
string, but we were calling it with a temporary string. Change
On Thu, Oct 26, 2017 at 5:44 PM, Zachary Turner wrote:
>
>
> On Thu, Oct 26, 2017 at 3:18 PM Don Hinton wrote:
>
>> On Thu, Oct 26, 2017 at 2:48 PM, Zachary Turner
>> wrote:
>>
>>> Seems fine, it would be nice if the workflow could be improved a little
>>> bit so that all you have to do is say
hintonda updated this revision to Diff 120538.
hintonda added a comment.
- Add ability to add breakpoints matching -W warnings.
https://reviews.llvm.org/D36347
Files:
utils/clangdiag.py
Index: utils/clangdiag.py
===
--- /dev/nul
SeanChense added a comment.
In https://reviews.llvm.org/D34774#908084, @kubamracek wrote:
> In https://reviews.llvm.org/D34774#907636, @SeanChense wrote:
>
> > Hi there, I am here to find help. Is there a way to get
> > `libMainThreadChecker.dylib` output ? Then we can analyze the output to
>
Author: labath
Date: Thu Oct 26 19:24:04 2017
New Revision: 316728
URL: http://llvm.org/viewvc/llvm-project?rev=316728&view=rev
Log:
Default to using in-tree clang for building test executables
Summary:
Using the in-tree clang should be the default test configuration as that
is the one compiler t
This revision was automatically updated to reflect the committed changes.
Closed by commit rL316728: Default to using in-tree clang for building test
executables (authored by labath).
Repository:
rL LLVM
https://reviews.llvm.org/D39215
Files:
lldb/trunk/CMakeLists.txt
lldb/trunk/lit/CMake
Author: jmolenda
Date: Thu Oct 26 19:21:55 2017
New Revision: 316727
URL: http://llvm.org/viewvc/llvm-project?rev=316727&view=rev
Log:
Add Arm Architecture plugin to the xcode project file.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj/project.pbxpro
On Thu, Oct 26, 2017 at 3:18 PM Don Hinton wrote:
> On Thu, Oct 26, 2017 at 2:48 PM, Zachary Turner
> wrote:
>
>> Seems fine, it would be nice if the workflow could be improved a little
>> bit so that all you have to do is say `clangdiag break
>> —error=“-Wcovered-switch”` or something . I think
hintonda updated this revision to Diff 120518.
hintonda added a comment.
- Maintain process id map for diagtool.
https://reviews.llvm.org/D36347
Files:
utils/clangdiag.py
Index: utils/clangdiag.py
===
--- /dev/null
+++ utils/cla
Ahh, sorry. While I feel strongly about 1 long term, going from 4 -> 2 is
already a win, so I see no reason to block this over that. We can then
work on going from 2 -> 1 later.
On Thu, Oct 26, 2017 at 4:57 PM Pavel Labath wrote:
> I haven't put this in yet. I was still waiting for a reaction
I haven't put this in yet. I was still waiting for a reaction from
Zachary about the two cmake vars, as he felt pretty strongly about
unifying to one. (I didn't want to do that as I would have to write
code for transforming /usr/bin/arm-linux-gnu-gcc-4.7 (and likes) into
/usr/bin/arm-linux-gnu-g++-
I think you now need to use `-DLLDB_TEST_C_COMPILER` and
`-DLLDB_TEST_CXX_COMPILER`
On Thu, Oct 26, 2017 at 4:40 PM Paul Robinson via Phabricator <
revi...@reviews.llvm.org> wrote:
> probinson added a comment.
>
> Has this gone in? I'm wondering because I starting playing with the
> monorepo, ra
probinson added a comment.
Has this gone in? I'm wondering because I starting playing with the monorepo,
ran cmake with -DLLDB_TEST_COMPILER=$PWD/bin/clang, and today's test failure
seems to be trying to build the test program with the system compiler (gcc)
rather than my copy of clang. But i
> On Oct 26, 2017, at 3:21 PM, Jason Molenda wrote:
>
>
>
>> On Oct 26, 2017, at 3:12 PM, Davide Italiano wrote:
>>
>> On Thu, Oct 26, 2017 at 3:04 PM, Jason Molenda wrote:
>>>
>>>
On Oct 26, 2017, at 10:24 AM, Davide Italiano via lldb-commits
wrote:
On Thu, Oct 26
> On Oct 26, 2017, at 3:12 PM, Davide Italiano wrote:
>
> On Thu, Oct 26, 2017 at 3:04 PM, Jason Molenda wrote:
>>
>>
>>> On Oct 26, 2017, at 10:24 AM, Davide Italiano via lldb-commits
>>> wrote:
>>>
>>> On Thu, Oct 26, 2017 at 10:04 AM, Stephane Sezer via lldb-commits
>>> wrote:
Au
On Thu, Oct 26, 2017 at 2:48 PM, Zachary Turner wrote:
> Seems fine, it would be nice if the workflow could be improved a little
> bit so that all you have to do is say `clangdiag break
> —error=“-Wcovered-switch”` or something . I think that gives the most
> intuitive usage for people, even it’s
On Thu, Oct 26, 2017 at 3:04 PM, Jason Molenda wrote:
>
>
>> On Oct 26, 2017, at 10:24 AM, Davide Italiano via lldb-commits
>> wrote:
>>
>> On Thu, Oct 26, 2017 at 10:04 AM, Stephane Sezer via lldb-commits
>> wrote:
>>> Author: sas
>>> Date: Thu Oct 26 10:04:20 2017
>>> New Revision: 316673
>>>
On Thu, Oct 26, 2017 at 3:00 PM, Greg Clayton via Phabricator <
revi...@reviews.llvm.org> wrote:
> clayborg added a comment.
>
> Each lldb.SBValue has accessors for the stuff in an execution context:
>
> ``
>
> lldb::SBTarget GetTarget();
> lldb::SBProcess GetProcess();
> lldb::SBThread GetT
> On Oct 26, 2017, at 10:24 AM, Davide Italiano via lldb-commits
> wrote:
>
> On Thu, Oct 26, 2017 at 10:04 AM, Stephane Sezer via lldb-commits
> wrote:
>> Author: sas
>> Date: Thu Oct 26 10:04:20 2017
>> New Revision: 316673
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=316673&view=rev
clayborg added a comment.
Each lldb.SBValue has accessors for the stuff in an execution context:
``
lldb::SBTarget GetTarget();
lldb::SBProcess GetProcess();
lldb::SBThread GetThread();
lldb::SBFrame GetFrame();
You could keep a global map of process ID to diagtool if you want?
W
Seems fine, it would be nice if the workflow could be improved a little bit
so that all you have to do is say `clangdiag break
—error=“-Wcovered-switch”` or something . I think that gives the most
intuitive usage for people, even it’s a bit harder to implement.
I also think user shouldn’t really h
hintonda added a comment.
Is there a way to associate a particular diagtool variable to an exe_ctx?
https://reviews.llvm.org/D36347
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
hintonda updated this revision to Diff 120492.
hintonda added a comment.
- Remove debugging print statement, and enhance help message.
https://reviews.llvm.org/D36347
Files:
utils/clangdiag.py
Index: utils/clangdiag.py
===
--- /
labath updated this revision to Diff 120491.
labath marked 4 inline comments as done.
labath added a comment.
Address review comments.
https://reviews.llvm.org/D35556
Files:
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/forward_list/Makefile
packa
labath marked 5 inline comments as done.
labath added inline comments.
Comment at:
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/forward_list/main.cpp:5
+{
+ std::forward_list empty{}, one_elt{47}, five_elts{1,22,333,,5};
+ ret
sas added a subscriber: fjricci.
sas added a comment.
In https://reviews.llvm.org/D39315#908284, @zturner wrote:
> So when you're using ds2 as the remote, are you still using the normal lldb
> test suite? `dotest.py`? If so, then we could have a test decorator that
> says `@expectedFailure(no
On Thu, Oct 26, 2017 at 12:39 PM, Stephane Sezer wrote:
> This changes nothing except for 32bit Windows, which used to not be able to
> benefit from ABISysV_i386 but can use it now. The ABI support is tested
> independently from Windows itself.
>
Sure, makes sense. I guess we should still be able
This changes nothing except for 32bit Windows, which used to not be able to
benefit from ABISysV_i386 but can use it now. The ABI support is tested
independently from Windows itself.
On Thu, Oct 26, 2017 at 10:25 AM Davide Italiano
wrote:
> On Thu, Oct 26, 2017 at 10:04 AM, Stephane Sezer via ll
Author: labath
Date: Thu Oct 26 12:08:34 2017
New Revision: 316688
URL: http://llvm.org/viewvc/llvm-project?rev=316688&view=rev
Log:
Fix TestMinidump for r316673
The test was asserting that we can only find one frame in the minidump.
Now that we have the default unwind plan from the ABI plugin, w
hintonda added a comment.
In https://reviews.llvm.org/D36347#908186, @zturner wrote:
> Do I understand correctly that this will insert breakpoints on *all* clang
> diagnostics? That's not necessarily bad, but I was under the impression
> originally that it would let you pick the diagnostics yo
clayborg added a comment.
Looks good.
https://reviews.llvm.org/D36347
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
clayborg added a comment.
The test suite can be run remotely if ds2 supports the "lldb-server platform"
packets. I'll be happy to help you get this going Stephane. Ping me internally
if interested.
https://reviews.llvm.org/D39315
___
lldb-commits
Hi,
None of us have commit access. Please submit for us.
Thanks once again
> -Original Message-
> From: Zachary Turner [mailto:ztur...@google.com]
> Sent: quinta-feira, 26 de outubro de 2017 16:34
> To: reviews+d38897+public+f7e86848ad3ba...@reviews.llvm.org
> Cc: Ana Julia Pereira Caeta
Nothing happened internally. Usually people submit their own patches after
they're accepted. If neither of you have commit access though, then you'll
need to let us know so that we can submit on your behalf.
On Thu, Oct 26, 2017 at 11:30 AM Gustavo Serra Scalet via Phabricator <
revi...@reviews.
hintonda updated this revision to Diff 120459.
hintonda added a comment.
- Enhance diagtool option to check, reset, print out current value.
https://reviews.llvm.org/D36347
Files:
utils/clangdiag.py
Index: utils/clangdiag.py
===
zturner added a comment.
So when you're using ds2 as the remote, are you still using the normal lldb
test suite? `dotest.py`? If so, then we could have a test decorator that says
`@expectedFailure(not(debugserver=ds2))` or something. Then, even though
you're the only one that can run it, at
gut added a comment.
In https://reviews.llvm.org/D38897#903581, @clayborg wrote:
> Looks fine. Thanks for doing the changes.
Hi, it's been already 4 days since this patch was accepted but not merged. Did
something happen internally or we just need to wait a little longer?
https://reviews.llv
sas added a comment.
In https://reviews.llvm.org/D39315#908251, @zturner wrote:
> In https://reviews.llvm.org/D39315#908246, @sas wrote:
>
> > Same thing here, I have no idea how to go about testing something specific
> > like this. Given that this is Windows Phone, it's even worse than simply
davide added a comment.
In https://reviews.llvm.org/D39315#908246, @sas wrote:
> Same thing here, I have no idea how to go about testing something specific
> like this. Given that this is Windows Phone, it's even worse than simply
> Windows Desktop because the only way to test is by doing remot
zturner added a comment.
In https://reviews.llvm.org/D39315#908246, @sas wrote:
> Same thing here, I have no idea how to go about testing something specific
> like this. Given that this is Windows Phone, it's even worse than simply
> Windows Desktop because the only way to test is by doing remo
sas added a comment.
Same thing here, I have no idea how to go about testing something specific like
this. Given that this is Windows Phone, it's even worse than simply Windows
Desktop because the only way to test is by doing remote debugging. I suppose
checking in binaries to the tree so we ca
zturner added a comment.
Ahh, you might also run the exact same test again but where you've loaded this
inside of main with `LoadLibrary` instead of relying on early binding by the
loader.
https://reviews.llvm.org/D39314
___
lldb-commits mailing l
zturner added a comment.
A test would be something like this:
// dll.cpp
BOOL WINAPI DllMain(HINSTANCE h, DWORD reason, void* reserved) {
return TRUE;
}
int __declspec(dllexport) DllFunc(int n) {
int x = n * n;
return x; // set breakpoint here
}
// main.cpp
int
clayborg accepted this revision.
clayborg added inline comments.
Comment at: utils/clangdiag.py:117
+disable(exe_ctx)
+else:
+getDiagtool(exe_ctx.GetTarget(), args.path[0])
hintonda wrote:
> clayborg wrote:
> > should probably verify that this
sas added a comment.
@clayborg: the follow-up to this change is in https://reviews.llvm.org/D39337,
where we implement `GetAddressClass()`.
https://reviews.llvm.org/D39315
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.
sas created this revision.
This function apparently is called only by addresses that are valid.
We mainly need to use the ISA class whenever is needed.
Depends on https://reviews.llvm.org/D39315.
Change by Walter Erquinigo
https://reviews.llvm.org/D39337
Files:
source/Plugins/ObjectFile/PE
zturner added a comment.
Do I understand correctly that this will insert breakpoints on *all* clang
diagnostics? That's not necessarily bad, but I was under the impression
originally that it would let you pick the diagnostics you wanted to insert
breakpoints on.
Also, What is the workflow for
sas added a comment.
In https://reviews.llvm.org/D19603#908130, @clayborg wrote:
> Does this need some ARM support where we strip bit zero in case the entry
> point is Thumb?
Good question. Somehow we never had any issue with this but I don't remember
explicitly checking for difference with t
hintonda added a comment.
Thanks for the feedback (addressed below).
btw, where should this module go?
Since it's intended for clang, and clang based tool, developers, I put it in
`clang/utils`, but Zackery suggested `lldb/examples/python` might be a better
place. Please let me know if anyone
sas updated this revision to Diff 120447.
sas added a comment.
Address comments by @clayborg.
https://reviews.llvm.org/D39315
Files:
source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
Index: source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
===
On Thu, Oct 26, 2017 at 10:04 AM, Stephane Sezer via lldb-commits
wrote:
> Author: sas
> Date: Thu Oct 26 10:04:20 2017
> New Revision: 316673
>
> URL: http://llvm.org/viewvc/llvm-project?rev=316673&view=rev
> Log:
> Allow SysV-i386 ABI on everything other than Apple targets
>
> Summary:
> This ma
davide requested changes to this revision.
davide added a comment.
This change should be unit-testable, no?
https://reviews.llvm.org/D39315
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb
clayborg added a comment.
Testing would include a test that dynamically loads a shared library and sets a
breakpoint it in. We have these tests, but I am guessing they are disabled on
windows probably because they might use "dlopen(...)" which is probably not
available on windows? I know we hav
This revision was automatically updated to reflect the committed changes.
Closed by commit rL316673: Allow SysV-i386 ABI on everything other than Apple
targets (authored by sas).
Repository:
rL LLVM
https://reviews.llvm.org/D39335
Files:
lldb/trunk/source/Plugins/ABI/SysV-i386/ABISysV_i386.
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
ok, just move the ARM detection out of the loop and use a
THUMB_ADDRESS_BIT_MASK for ARM symbols and this is good to go.
https://reviews.llvm.org/D39315
_
davide added a comment.
In https://reviews.llvm.org/D39314#908115, @sas wrote:
> In https://reviews.llvm.org/D39314#908065, @davide wrote:
>
> > can you please try adding a test for this one? :)
>
>
> To be fully honest, I'm not 100% sure how I'm supposed to add tests for this.
> I looked throug
sas requested review of this revision.
sas added a comment.
I saw the `bool is_arm = ` pattern only in `ObjectFileMachO.cpp`. I'm not sure
about the specifics for Darwin targets, but having an object file with some
functions in ARM and some functions in Thumb is valid, so I think checking for
e
Author: sas
Date: Thu Oct 26 10:04:20 2017
New Revision: 316673
URL: http://llvm.org/viewvc/llvm-project?rev=316673&view=rev
Log:
Allow SysV-i386 ABI on everything other than Apple targets
Summary:
This matches other SysV ABIs that are different on Apple and non-Apple targets,
like `ABISysV_arm.c
clayborg added a comment.
Does this need some ARM support where we strip bit zero in case the entry point
is Thumb?
https://reviews.llvm.org/D19603
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/list
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
Very close. Thanks for making the changes. Just a few nits.
Comment at: utils/clangdiag.py:66
+def setDiagBreakpoint(frame, bp_loc, dict):
+id = frame.FindV
sas added a comment.
In https://reviews.llvm.org/D39314#908065, @davide wrote:
> can you please try adding a test for this one? :)
To be fully honest, I'm not 100% sure how I'm supposed to add tests for this. I
looked through the directories containing unit tests and didn't find anything
spec
clayborg requested changes to this revision.
clayborg added inline comments.
This revision now requires changes to proceed.
Comment at: source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp:651-659
+ ArchSpec header_arch;
+ GetArchitecture(header_arch);
+
sas created this revision.
Herald added subscribers: kristof.beyls, aemerson.
This matches other SysV ABIs that are different on Apple and non-Apple targets,
like `ABISysV_arm.cpp` for instance.
https://reviews.llvm.org/D39335
Files:
source/Plugins/ABI/SysV-i386/ABISysV_i386.cpp
Index: sour
kubamracek added a comment.
In https://reviews.llvm.org/D34774#907636, @SeanChense wrote:
> Hi there, I am here to find help. Is there a way to get
> `libMainThreadChecker.dylib` output ? Then we can analyze the output to
> generate a report ?
Hi, what are you trying to do? What info are you
davide added a comment.
can you please try adding a test for this one? :)
https://reviews.llvm.org/D39314
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
Wow. I didn't realize windows support didn't do any of this. Looks good. Zach
will want to ok this as he is one of the main windows contributors.
https://reviews.llvm.org/D39314
__
Note that $ is a valid character in a MSVC-mangled symbol name. So, I
don't think it will work for that reason alone. FWIW, I also don't like
the {,,} syntax very much, but if you read on there's a simpler ! syntax
that is pretty nice.
libfoo!symbolname
On Thu, Oct 26, 2017 at 9:30 AM Greg Cla
> On Oct 25, 2017, at 6:05 PM, Zachary Turner wrote:
>
>
>
> On Wed, Oct 25, 2017 at 4:59 PM Jim Ingham via Phabricator
> mailto:revi...@reviews.llvm.org>> wrote:
> jingham added a comment.
>
> Note, BTW, we absolutely need some way to say "this symbol from this
> library". But first of al
SeanChense added a comment.
Hi there, I am here to find help. Is there a way to get
`libMainThreadChecker.dylib` output ? Then we can analyze the output to
generate a report ?
https://reviews.llvm.org/D34774
___
lldb-commits mailing list
lldb-com
CarlosAlbertoEnciso added a comment.
In https://reviews.llvm.org/D39283#907100, @tberghammer wrote:
> Hi Carlos,
>
> Sorry for not responding to your related e-mails lately.
Hi Tamas,
There is no need for apologies. You have help me a lot in setting LLDB and be
able to run the test suite. (Wi
71 matches
Mail list logo
