| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 313327
|
|
|
|
| |
llvm-svn: 313305
|
|
|
|
|
|
| |
get included in headermaps or put in a CopyFiles phase.
llvm-svn: 313296
|
|
|
|
| |
llvm-svn: 313293
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When introduced, breakpoint names were just tags that you could
apply to breakpoints that would allow you to refer to a breakpoint
when you couldn't capture the ID, or to refer to a collection of
breakpoints.
This change makes the names independent holders of breakpoint options
that you can then apply to breakpoints when you add the name to the
breakpoint. It adds the "breakpoint name configure" command to set
up or reconfigure breakpoint names. There is also full support for
then in the SB API, including a new SBBreakpointName class.
The connection between the name and the breakpoints
sharing the name remains live, so if you reconfigure the name, all the
breakpoint options all change as well. This allows a quick way
to share complex breakpoint behavior among a bunch of breakpoints, and
a convenient way to iterate on the set.
You can also create a name from a breakpoint, allowing a quick way
to copy options from one breakpoint to another.
I also added the ability to make hidden and delete/disable protected
names. When applied to a breakpoint, you will only be able to list,
delete or disable that breakpoint if you refer to it explicitly by ID.
This feature will allow GUI's that need to use breakpoints for their
own purposes to keep their breakpoints from getting accidentally
disabled or deleted.
<rdar://problem/22094452>
llvm-svn: 313292
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch simplifies LLVM's lit infrastructure by enforcing an ordering
that a site config is always run before a source-tree config.
A significant amount of the complexity from lit config files arises from
the fact that inside of a source-tree config file, we don't yet know if
the site config has been run. However it is *always* required to run
a site config first, because it passes various variables down through
CMake that the main config depends on. As a result, every config
file has to do a bunch of magic to try to reverse-engineer the location
of the site config file if they detect (heuristically) that the site
config file has not yet been run.
This patch solves the problem by emitting a mapping from source tree
config file to binary tree site config file in llvm-lit.py. Then, during
discovery when we find a config file, we check to see if we have a
target mapping for it, and if so we use that instead.
This mechanism is generic enough that it does not affect external users
of lit. They will just not have a config mapping defined, and everything
will work as normal.
On the other hand, for us it allows us to make many simplifications:
* We are guaranteed that a site config will be executed first
* Inside of a main config, we no longer have to assume that attributes
might not be present and use getattr everywhere.
* We no longer have to pass parameters such as --param llvm_site_config=<path>
on the command line.
* It is future-proof, meaning you don't have to edit llvm-lit.in to add
support for new projects.
* All of the duplicated logic of trying various fallback mechanisms of
finding a site config from the main config are now gone.
One potentially noteworthy thing that was required to implement this
change is that whereas the ninja check targets previously used the first
method to spawn lit, they now use the second. In particular, you can no
longer run lit.py against the source tree while specifying the various
`foo_site_config=<path>` parameters. Instead, you need to run
llvm-lit.py.
Differential Revision: https://reviews.llvm.org/D37756
llvm-svn: 313270
|
|
|
|
|
|
|
| |
std::unique_ptr is pretty much a drop-in replacement here. Also remove nullptr
checks that are doing nothing.
llvm-svn: 313265
|
|
|
|
|
|
|
|
| |
The auto-continue test was using the new (better) name
for providing commands (-C) but I haven't checked in that change
yet. Put the test back to the old way for now.
llvm-svn: 313221
|
|
|
|
|
|
| |
Adding that now.
llvm-svn: 313216
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(core/minidump)
The main change is to avoid setting the process state as running when
debugging core/minidumps (details in the bug).
Also included a few small, related fixes around how the errors propagate in
this case.
patch by lemo
Bug: https://bugs.llvm.org/show_bug.cgi?id=34532
Differential Revision: https://reviews.llvm.org/D37651
llvm-svn: 313210
|
|
|
|
| |
llvm-svn: 313183
|
|
|
|
| |
llvm-svn: 313181
|
|
|
|
|
|
|
| |
On Windows a process can't delete its own current direcotry, that's why the test
needs to return to the original direcotry before removing newdir.
llvm-svn: 313113
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When LLDB loads "external" modules it looks at the
presence of DW_AT_GNU_dwo_name.
However, when the already created module
(corresponding to .dwo itself) is being processed,
it will see the presence of DW_AT_GNU_dwo_name
(which contains the name of dwo file) and
will try to call ModuleList::GetSharedModule again.
In some cases (i.e. for empty files) Clang 4.0
generates a *.dwo file which has DW_AT_GNU_dwo_name,
but no DW_AT_comp_dir. In this case the method
ModuleList::GetSharedModule will fail and
the warning will be printed. To workaround this issue,
one can notice that in this case we don't actually need
to try to load the already loaded module (corresponding to .dwo).
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D37295
llvm-svn: 313083
|
|
|
|
|
|
|
|
|
| |
A clang change caused the inclusion of `llvm::Type` and
`lldb_private::Type` to be pulled into the global namespace due to the
`using namespace llvm;` and `using namespace lldb_private;`. Explicitly
qualify the `Type` to resolve the ambiguity. NFC
llvm-svn: 312841
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even though the content of the minidump does not change in a debugging session,
frames can't be indiscriminately be cached since modules and symbols can be
explicitly added after the minidump is loaded.
The fix is simple, just let the base Thread::ClearStackFrames() do its job.
submitted by amccarth on behalf of lemo
Bug: https://bugs.llvm.org/show_bug.cgi?id=34510
Differential Revision: https://reviews.llvm.org/D37527
llvm-svn: 312735
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Test was skipped because -data-evaluate-expression was thought
to not work on globals. This is not the case - the issue was clang
removes debug info for globals in cpp files that are not used.
Add a reference to the globals in question, and fix memory patter in
test to match memory pattern in testcase.
Reviewers: ki.stfu, abidh
Reviewed By: ki.stfu
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D37533
llvm-svn: 312726
|
|
|
|
|
|
|
|
|
|
| |
Turns out WITH_LOCKDOWN define changes the struct layout and constructor implementation for RNBSocket which is used in debugserver.cpp, so we need to make sure this is consistent.
In the future we should change WITH_LOCKDOWN to be configured in a generated header, but for now we can just set it correctly.
<rdar://problem/33900552>
llvm-svn: 312666
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D37441
llvm-svn: 312562
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal of this patch is twofold:
First, it removes a wrong comment (at least, not correctly describing
what the function does).
Then, it rewrites the function to use a StringSwitch where the
registers are enumerated explicitly instead of being computed
programmatically. Other than being much shorter, it's much easier to
read (and given the ABI won't change anytime soon, I don't think
there's need to generalize).
While here, I added an assert that the register name is always empty,
as the previous implementation of the function assumed so.
Differential Revision: https://reviews.llvm.org/D37420
llvm-svn: 312501
|
|
|
|
| |
llvm-svn: 312457
|
|
|
|
| |
llvm-svn: 312454
|
|
|
|
| |
llvm-svn: 312453
|
|
|
|
|
|
|
|
|
| |
This was failing on FreeBSD prior to r312430.
Patch by Vignesh Balu.
Differential Revision: https://reviews.llvm.org/D32522
llvm-svn: 312431
|
|
|
|
|
|
|
|
|
|
|
|
| |
attach by pid worked when running from the directory from which the
target was launched, but failed from a different directory. Use the
kern.proc.pathname sysctl to locate the target, falling back to the
original case of the target's argv[0] if that fails. Based on a patch
from Vignesh Balu.
Differential Revision: https://reviews.llvm.org/D32271
llvm-svn: 312430
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
-var-update calls CMICmdCmdVarUpdate::ExamineSBValueForChange to check if a varObj has been updated. It checks that the varObj is updated, then recurses on all of its children. If a child is a pointer pointing back to a parent node, this will result in an infinite loop, and lldb-mi hanging.
The problem is exposed by packages/Python/lldbsuite/test/tools/lldb-mi/variable/TestMiVar.py, but this test is skipped everywhere.
This patch changes ExamineSBValueForChange to not traverse children of varObjs that are pointers.
Reviewers: ki.stfu, zturner, clayborg, abidh
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D37154
llvm-svn: 312270
|
|
|
|
| |
llvm-svn: 312267
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(lldb) target create "tst"
Current executable set to 'tst' (powerpc64le).
(lldb) disassemble -n main
tst`main:
tst[0x7b0] <+0>: addis 2, 12, 2
tst[0x7b4] <+4>: addi 2, 2, 30544
tst[0x7b8] <+8>: mflr 0
Wihout the patch, the endianess was incorrect:
(lldb) target create "tst"
Current executable set to 'tst' (powerpc64).
(lldb) disassemble -n main
tst`main:
tst[0x7b0] <+0>: .long 0x02004c3c ; unknown opcode
tst[0x7b4] <+4>: rlwimi 23, 3, 8, 8, 28
tst[0x7b8] <+8>: lhzu 16, 2172(2)
tst[0x7bc] <+12>: .long 0x100001f8 ; unknown opcode
Simple binary used is identified as:
$ file tst
tst: ELF 64-bit LSB shared object, 64-bit PowerPC or cisco 7500, version
1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, for
GNU/Linux 3.2.0, BuildID[sha1]=17a8fa2b24ce2837ba6625fabb34e6b29c6c5db7,
not stripped
Patch by Gustavo Serra Scalet <gustavo.scalet@eldorado.org.br>
Differential Revision: https://reviews.llvm.org/D36804
llvm-svn: 312151
|
|
|
|
|
|
|
|
|
|
| |
The socket bind address should either be localhost or anyaddress. This bug in the listen behavior was preventing lldb-server from opening sockets for non-localhost connections.
The added test verifies that opening an anyaddress socket works and has a non-zero port assignment.
This should resolve PR34183.
llvm-svn: 312008
|
|
|
|
| |
llvm-svn: 311978
|
|
|
|
| |
llvm-svn: 311786
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The DWP (DWARF package) format is used to pack multiple dwo files
generated by split-dwarf into a single ELF file to make distributing
them easier. It is part of the DWARFv5 spec and can be generated by
dwp or llvm-dwp from a set of dwo files.
Caviats:
* Only the new version of the dwp format is supported (v2 in GNU
numbering schema and v5 in the DWARF spec). The old version (v1) is
already deprecated but binutils 2.24 still generates that one.
* Combining DWP files with module debugging is not yet supported.
Subscribers: emaste, mgorny, aprantl
Differential Revision: https://reviews.llvm.org/D36062
llvm-svn: 311775
|
|
|
|
|
|
|
| |
but while I was at it I converted the example to use
properties, since that's much nicer looking.
llvm-svn: 311679
|
|
|
|
|
|
|
|
| |
to match the changes Saleem Abdulrasool committed in r311579. Fixes
a testsuite failure now that the testsuite expects a 16 bit return
value for thsi reg.
llvm-svn: 311627
|
|
|
|
|
|
|
|
|
|
|
|
| |
in a dSYM, and it's a version 2 DBGSourcePathRemapping,
in addition to the build/source paths specified, add
build/source paths with the last two filename components
removed. This more generic remapping can sometimes
help lldb to find the correct source file in complex
projects.
<rdar://problem/33973545>
llvm-svn: 311622
|
|
|
|
| |
llvm-svn: 311590
|
|
|
|
|
|
|
| |
I had built without python bindings and did not find this in the grep
output. Adjust the test output for the printing format update.
llvm-svn: 311582
|
|
|
|
|
|
|
|
|
| |
The FXSAVE member `ftw` (FPU Tag Word) was given the wrong size (8-bit)
instead of the correct width (16-bit) as per the x87 Programmer's
Manual. Adjust this to ensure that we print out the complete value for
the register.
llvm-svn: 311579
|
|
|
|
|
|
| |
Remove some stray ';' that were in the source code. NFC.
llvm-svn: 311577
|
|
|
|
| |
llvm-svn: 311484
|
|
|
|
|
|
|
|
| |
JSON serializer fails to escape newlines and backslashes. Let's fix that.
Differential Revision: https://reviews.llvm.org/D34322
llvm-svn: 311483
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: lldb-argdumper only needs lldbUtility to successfully build and link.
Reviewers: beanz, zturner, labath
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D36948
llvm-svn: 311399
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Process/gdb-remote test now requires the LLVMTestingSupport library
that is not installed by LLVM. As a result, when doing an out-of-source
build it fails being unable to find the library. To solve that, build
a local copy of the library when building LLDB with unittests and LLVM
sources available. This is based on how we deal with bundled gtest
sources.
Differential Revision: https://reviews.llvm.org/D36886
llvm-svn: 311355
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add explicit linkage to the necessary system libraries in the Host
library. Otherwise, the library fails to build with -Wl,--as-needed.
The system libraries ended up being listed on the linker command-line
before the static libraries needing them, resulting in --as-needed
stripping them.
Listing the dependent libraries explicitly is the canonical way of
declaring libraries in CMake. It guarantees that the system library
dependencies will be correctly propagated to reverse dependencies.
The code used to link libraries reuses existing EXTRA_LIBS variable,
copying code from other parts of LLDB. We might eventually remove
the direct use of system libraries in the programs; however, I would
prefer if we focused on fixing the build regressions in 5.0 branch
first, and went further after the release.
Differential Revision: https://reviews.llvm.org/D36885
llvm-svn: 311354
|
|
|
|
| |
llvm-svn: 311245
|
|
|
|
| |
llvm-svn: 311244
|
|
|
|
|
|
|
|
| |
"Prevent negative chars from being sign-extended into isprint and isspace which take and int and crash if the int is negative"
https://reviews.llvm.org/D36620
llvm-svn: 311207
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Core library calls functions provided by the curses library. Add
an appropriate explicit LINK_LIBS to ${CURSES_LIBRARIES} to propagate
the dependency correctly within the build system.
It seems that so far the linkage was handled by some kind of implicit
magic LLDB_SYSTEM_LIBS variable. However, it stopped working for
unittests as the curses libraries are passed before the LLDBCore
library, resulting in `-Wl,--as-needed` stripping the yet-unused library
before it is required by LLDBCore, and effectively breaking the build.
I think it's better to focus on listing all the dependencies explicitly
and let CMake propagate them rather than trying to figure out why this
hack stopped working.
This is also more consistent with LLVM where the curses linkage
in LLVMSupport is expressed directly in the library rather than deferred
to the final programs.
Differential Revision: https://reviews.llvm.org/D36358
llvm-svn: 311122
|
|
|
|
|
|
|
| |
Another case of this was responsible for the whitespace conflict
in D34776.
llvm-svn: 311003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Enable i386 ABI creation for freebsd
* Added an extra argument in ABISysV_i386::PrepareTrivialCall for mmap
syscall
* Unlike linux, the last argument of mmap is actually 64-bit(off_t).
This requires us to push an additional word for the higher order bits.
* Prior to this change, ktrace dump will show mmap failures due to
invalid argument coming from the 6th mmap argument.
Patch by Karnajit Wangkhem
Differential Revision: https://reviews.llvm.org/D34776
llvm-svn: 311002
|