Author: jingham
Date: Mon Dec 4 18:50:45 2017
New Revision: 319731
URL: http://llvm.org/viewvc/llvm-project?rev=319731&view=rev
Log:
Add target.process.stop-on-exec setting, and obey it.
Also add a test. There should also be control for this
in ProcessLaunchInfo and a "target launch" flag, but
Admittedly I was on mobile when I wrote that so I didn't have code to look
at. I assumed from the pattern and the few function signatures I saw that
GPR etc were inheriting from thread_state_t, and that was how the cast
worked at all. A quick look at the code suggests this is not the case
though.
Author: jingham
Date: Mon Dec 4 18:34:05 2017
New Revision: 319730
URL: http://llvm.org/viewvc/llvm-project?rev=319730&view=rev
Log:
Clean up stop hook output in case a hook restarts.
I was warning about the fact that this will abort
further stop hooks, but didn't check that there WAS
a further
> On Dec 4, 2017, at 6:02 PM, Zachary Turner wrote:
>
> It almost looks to me like this should be using aggregation instead of
> inheritance. That would add a 3rd option (mark it mutable).
I don't have my head wrapped around your suggestion. Do you mean that 'const
GPR &' and friends should b
It almost looks to me like this should be using aggregation instead of
inheritance. That would add a 3rd option (mark it mutable). That said,
nothing wrong with using this approach either
On Mon, Dec 4, 2017 at 5:43 PM Vedant Kumar via Phabricator via
lldb-commits wrote:
> vsk created this revisi
vsk created this revision.
Herald added a subscriber: javed.absar.
A few methods in RegisterContext classes accept const objects which are
cast to a non-const thread_state_t. Instead of dropping const-ness, it
might be simpler and more ergonomic to just not mark the objects const.
This fixes a sl
jasonmolenda accepted this revision.
jasonmolenda added a comment.
This revision is now accepted and ready to land.
Ah I see, I bet I assumed it was marked weak but it never was. patch looks
good to me.
https://reviews.llvm.org/D40812
___
lldb-com
vsk added a comment.
Ah, sorry, I should have mentioned that the header vending
compression_decode_buffer() does not provide the 'weak_import' attribute (as
far as I can see!). If you change your example to drop 'weak_import' from foo,
I think it will be closer to the current situation.
https
jasonmolenda added a comment.
The output looks like this:
% make
echo 'int foo() { return 5; }' > mylib.c
echo "int foo() __attribute__((weak_import)); int printf(const char *, ...);
int main() { if (foo) printf (\"have foo() %d\\\n\", foo()); else printf(\"do
not have foo\\\n\"); return 0; }"
jasonmolenda added a comment.
all:
echo 'int foo() { return 5; }' > mylib.c
echo "int foo() __attribute__((weak_import)); int printf(const char *,
...); int main() { if (foo) printf (\"have foo() %d\\\n\", foo()); else
printf(\"do not have foo\\\n\"); return 0; }" > main.c
jasonmolenda added a comment.
I don't think that is correct. here's an example in the form of a makefile.
the main binary calls foo() which is weak linked from a library. In the first
run, foo() is present in the library. In the second run, the library is
rebuilt so foo() is absent. The be
vsk created this revision.
Null-checking functions which aren't marked 'weak_import' is a no-op
(the compiler rewrites the check to 'true'), regardless of whether a
library providing its definition is weak-linked.
Remove the no-op checks to clean up the code and silence
-Wpointer-to-bool.
https
vsk added a comment.
In https://reviews.llvm.org/D40757#943483, @labath wrote:
> If the "excuse" for not following llvm here is that these structs mirror
> apple headers, should we restrict these warnings only to the relevant files
> (e.g. everything in `source/Plugins/Language/ObjC`)?
>
> I do
Author: aaronballman
Date: Mon Dec 4 12:46:43 2017
New Revision: 319694
URL: http://llvm.org/viewvc/llvm-project?rev=319694&view=rev
Log:
Switch from C++1z to C++17; corresponds to r319688 in Clang.
Modified:
lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusNameParser.cpp
Modified: lld
> On Dec 2, 2017, at 3:36 PM, Zachary Turner wrote:
>
> That said, it does seem to make more sense as something you would do in the
> main lldb executable, and not in library code.
>
Yes, if we want to support it we need to make an SB API to turn it on. You
can't turn it on in the driver by
Yeah, just a quick note about ds2, this is the current status of supported
platforms:
* Linux (x86/x86_64/arm/aarch64), used for debugging processes on "classic"
linux (Ubuntu, centOS, etc), Android, as well as Tizen.
* Windows (x86/x86_64/arm), used to debug processes on Windows Desktop,
Windows P
This revision was automatically updated to reflect the committed changes.
Closed by commit rL319653: Makefile.rules: compile all tests with
-fno-limit-debug-info (authored by labath).
Repository:
rL LLVM
https://reviews.llvm.org/D40717
Files:
lldb/trunk/packages/Python/lldbsuite/test/expre
Author: labath
Date: Mon Dec 4 05:31:56 2017
New Revision: 319653
URL: http://llvm.org/viewvc/llvm-project?rev=319653&view=rev
Log:
Makefile.rules: compile all tests with -fno-limit-debug-info
Summary:
This flag is on by default for darwin and freebsd, but off for linux.
Without it, clang will s
The reason you hit the assert there, is because you're running lldb on
an un-linked object file. When you link the file, the linker will
resolve these relocations and they will disappear. This is also the
reason you got those errors after removing the assert (you were
trying to parse unrelocated d
labath added a comment.
If the "excuse" for not following llvm here is that these structs mirror apple
headers, should we restrict these warnings only to the relevant files (e.g.
everything in `source/Plugins/Language/ObjC`)?
I don't particularly care about whether we do, but I wanted to throw
Gdb has no issues with this use case. I'm pretty sure this is a
problem with how our posix dynamic linker plugin catches these events.
I've asked eugene to look into that.
On 1 December 2017 at 18:58, Jim Ingham wrote:
> The fact that this passes on macOS likely does mean the general mechanism
>
On 1 December 2017 at 19:42, Jim Ingham wrote:
> This certainly should be cleared up and centralized. I'm not quite as sure
> it should be in Platform however. For instance, macOS has the DebugSymbols
> framework that allows users to specify a local lookup tool to find symbol
> files given a
22 matches
Mail list logo
