> On Jun 22, 2018, at 5:20 PM, Jim Ingham wrote:
>
> This is very cool!
>
> Could we make a base class for lldb commands in the lldb module that provides
> register_lldb_command? Then you wouldn't have to copy and paste this
> boiler-plate in every command file. Now that you have a gener
Author: gclayton
Date: Fri Jun 22 16:34:24 2018
New Revision: 335401
URL: http://llvm.org/viewvc/llvm-project?rev=335401&view=rev
Log:
Update cmdtemplate.py to use best pratices.
Fixes include:
- fix all lint errors
- add code that will automatically register and LLDB command classes by
detectin
clayborg added a comment.
Would love to remove the "accept_zeroes" argument everywhere. Too much matching
happens in LLDB and we can't have multiple shared libraries claiming zeros as
their UUID
Comment at: include/lldb/Utility/UUID.h:54
+ void SetBytes(const void *uuid_byte
aprantl accepted this revision.
aprantl added inline comments.
This revision is now accepted and ready to land.
Comment at: tools/lldb-mi/MICmdCmdExec.cpp:137
+ auto successHandler = [this] {
+// CODETAG_DEBUG_SESSION_RUNNING_PROG_RECEIVED_SIGINT_PAUSE_PROGRAM
+if (!CMID
aprantl added a comment.
People might have a legitimate reason to debug very old code, e.g., for
backporting security fixes or similar. On the other hand one might argue that
they could just do this with a debugger from the same era.
https://reviews.llvm.org/D48500
_
davide added a comment.
I think it's fair and correct supporting everything we can, but I guess
`llvm-gcc` is largely dead at this point.
https://reviews.llvm.org/D48500
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.or
aprantl added a comment.
I don't have a problem with dropping compatibility with llvm-gcc in LLDB, but I
should point out that LLDB generally wants to be able to debug code produced by
a wide range of compilers, including old ones.
https://reviews.llvm.org/D48500
___
labath added a comment.
In https://reviews.llvm.org/D48463#1140861, @teemperor wrote:
> Adding Pavel because he wrote the PrintAsync code.
>
> Also @labath: Can you tell me what variables/functionality the
> `m_output_mutex` in Editline.cpp is supposed to shield? I don't see any
> documentation
Author: adrian
Date: Fri Jun 22 13:26:53 2018
New Revision: 335386
URL: http://llvm.org/viewvc/llvm-project?rev=335386&view=rev
Log:
Mark this test as no debuginfo
Modified:
lldb/trunk/packages/Python/lldbsuite/test/python_api/hello_world/TestHelloWorld.py
Modified:
lldb/trunk/packages/Pyt
>
> I'm not sure if there is a suitable place for that function. This is
> needed in "ObjectFileMachO" and two dynamic loader plugins.
Then your factory idea may be the next best thing. While we're at it, maybe
we can remove the UUID::SetBytes() from the public interface, and make the
UUID an im
lemo added a comment.
> I'm not sure if there is a suitable place for that function. This is
> needed in "ObjectFileMachO" and two dynamic loader plugins.
Then your factory idea may be the next best thing. While we're at it, maybe
we can remove the UUID::SetBytes() from the public interface, an
labath added a comment.
In https://reviews.llvm.org/D48479#1141067, @lemo wrote:
> One solution might be to encapsulate the MachO convention in the MachO
>
> code: check in there (maybe through a helper function) if the UUID is
> "000...0" and map it to the empty UUID in that case. The UUID in
lemo added subscribers: clayborg, labath, sas.
lemo added a comment.
> However, during parsing you need to know the meaning of a "...0" UUID.
> In a MachO file (at least based on the comments in the code) this value is
> used to denote the fact that the object file has no UUID. For elf, a
>
>
> However, during parsing you need to know the meaning of a "...0" UUID.
> In a MachO file (at least based on the comments in the code) this value is
> used to denote the fact that the object file has no UUID. For elf, a
> "000..0" build-id is a perfectly valid identifier (and the lack of a
>
labath updated this revision to Diff 152530.
labath added a comment.
Delete copy constructor.
https://reviews.llvm.org/D48479
Files:
include/lldb/Utility/UUID.h
source/API/SBModuleSpec.cpp
source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
source/Plugins/DynamicLoa
labath added a comment.
In https://reviews.llvm.org/D48479#1140927, @lemo wrote:
> > The slight complication here is that
> > some clients (MachO) actually use the all-zero notation to mean "no UUID
> > has been set". To keep this use case working, I have introduced an
> > additional argument
apolyakov added a comment.
Would be really nice to get review of this patch before this weekend. Thanks
for your time, folks.
https://reviews.llvm.org/D47992
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/ma
davide created this revision.
davide added reviewers: friss, aprantl, clayborg, labath.
Herald added a subscriber: JDevlieghere.
To the best of my understanding modern compilers handle all these cases
correctly. So, I think this is basically dead code.
https://reviews.llvm.org/D48500
Files:
clayborg added inline comments.
Comment at: source/Core/Debugger.cpp:988-1004
+ bool should_forward = false;
+ {
+// We check if any user requested to delay output to a later time
+// (which is designated by m_delayed_output_counter being not 0).
+std::lock_guard gu
lemo added a comment.
> The slight complication here is that
> some clients (MachO) actually use the all-zero notation to mean "no UUID
> has been set". To keep this use case working, I have introduced an
> additional argument to the UUID constructor, which specifies whether an
> all-zero vect
> On Jun 22, 2018, at 4:05 AM, Pavel Labath wrote:
>
> On Wed, 20 Jun 2018 at 23:21, Jim Ingham wrote:
>>
>> It is not uncommon that you would be parsing the DWARF for module A and find
>> a type that is only known as a forward declaration. In that case, lldb will
>> look through the other
teemperor added a reviewer: labath.
teemperor added a subscriber: labath.
teemperor added a comment.
Adding Pavel because he wrote the PrintAsync code.
Also @labath: Can you tell me what variables/functionality the `m_output_mutex`
in Editline.cpp is supposed to shield? I don't see any documenta
> On Jun 22, 2018, at 3:19 AM, Pavel Labath via Phabricator
> wrote:
>
> labath added a comment.
>
> I think this would be a very nice feature for lldb. Thank you for working on
> this.
>
> However, I am somewhat worried about how you're hooking the expression
> completer into the completi
Author: labath
Date: Fri Jun 22 06:13:29 2018
New Revision: 335344
URL: http://llvm.org/viewvc/llvm-project?rev=335344&view=rev
Log:
Android.rules: Use libc++ by default
libstdc++ will soon be dropped from the android NDK. This patch makes
sure we are prepared for that by using libc++ in tests by
labath created this revision.
labath added reviewers: clayborg, sas, lemo, davide.
Herald added subscribers: arichardson, emaste.
Herald added a reviewer: espindola.
During the previous attempt to generalize the UUID class, it was
suggested that we represent invalid UUIDs as length zero (previousl
On Wed, 20 Jun 2018 at 23:21, Jim Ingham wrote:
>
> It is not uncommon that you would be parsing the DWARF for module A and find
> a type that is only known as a forward declaration. In that case, lldb will
> look through the other Modules' debug info for a real definition, parse that
> and im
labath added a comment.
I think this would be a very nice feature for lldb. Thank you for working on
this.
However, I am somewhat worried about how you're hooking the expression
completer into the completion machinery. I think this should be cleaned up
first.
Comment at:
p
27 matches
Mail list logo
