| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: PPC64's auxvec has a special key that must be ignored.
Reviewers: clayborg, labath
Reviewed By: clayborg, labath
Subscribers: alexandreyy, lbianc
Differential Revision: https://reviews.llvm.org/D43771
Patch by Leandro Lupori <leandro.lupori@gmail.com>.
llvm-svn: 328486
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
physical/virtual addresses
Summary:
First attempt at landing D42145 was reverted because it caused test
failures on some android devices. It turned out this was because these
devices had vdso modules with differing physical and virtual addresses.
This was not caught earlier because all of the modules in our tests
either lack physical addresses or have them identical to virtual ones.
In the discussion on the patch, we came to the conclusion that in the
scenario where we are merely setting a load address of a module (for
example from a dynamic loader plugin), we should always use virtual
addresses (i.e., preserve status quo). This patch adds a test to make
sure we don't regress in that direction.
Reviewers: owenpshaw
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D44738
llvm-svn: 328485
|
|
|
|
|
|
| |
<rdar://problem/36035075>, <rdar://problem/36035039>
llvm-svn: 328389
|
|
|
|
|
|
| |
installing in the man page directory.
llvm-svn: 328383
|
|
|
|
|
|
| |
from targets.
llvm-svn: 328382
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This one will be used to print statistics about lldb sessions
(including, e.g. number of expression evaluation succeeded or
failed). I decided to commit the skeleton first so that we have
a clean reference on how a command should be implemented.
My future commits are going to populate this command and test
it.
<rdar://problem/36555975>
llvm-svn: 328378
|
|
|
|
|
|
| |
archs.
llvm-svn: 328374
|
|
|
|
| |
llvm-svn: 328373
|
|
|
|
|
|
|
|
|
|
| |
It wasn't even registered.
(lldb) apropos args
No commands found pertaining to 'args'. Try 'help' to see
a complete list of debugger commands.
llvm-svn: 328370
|
|
|
|
|
|
|
| |
I'm going to add a new commend so I figured I could do
some spring cleaning.
llvm-svn: 328368
|
|
|
|
| |
llvm-svn: 328365
|
|
|
|
| |
llvm-svn: 328278
|
|
|
|
|
|
|
|
|
| |
compiland
Some PDB Symbols don't have line information. Use the section contributions to determine their compiland.
This is useful to determine the parent compiland for PDBSymbolTypeData, i.e. variables.
llvm-svn: 328232
|
|
|
|
|
|
| |
type from a PDB
llvm-svn: 328230
|
|
|
|
| |
llvm-svn: 328176
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- postmortem tests: make sure the core files are created in the build
folder
- TestSourceManager: copy the .c file into the build dir before
modifying it
- TestLogging: create log files in the build folder
After these changes I get a clean test run (on linux) even if I set the
source tree to be read only. It's possible some of the skipped/xfailed
tests are still creating files in the source tree, but at the moment, I
don't have plans to go hunting for those.
llvm-svn: 328106
|
|
|
|
|
|
|
|
|
|
|
| |
As suggested by Pavel on lldb-commits. Originally I picked os.system
because it was so much more simple than the subprocess module, but that
no longer holds true after yesterday's hack in r328020. This is what it
should've been in the first place.
Differential revision: https://reviews.llvm.org/D44728
llvm-svn: 328089
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The issue was that the ASTDumper was being passed a null pointer
(because we did not create any declaration for the operator==). The
crash was in logging code, so it only manifested it self if you ran the
tests with logging enabled (like our bots do).
Given that this is logging code and the rest of the debugger is fine
with the declaration being null, I just make sure the logging code can
handle it as well. Right now I just do the null check in
ClangExpressionDeclMap, but if the ASTDumper class is meant to be a
debugging/logging aid, then it might be a good idea move the check
inside the class itself.
llvm-svn: 328088
|
|
|
|
|
|
|
|
|
|
|
|
| |
- use more goodies from Makefile.rules to correctly build a 32-bit
binary.
- avoid hardcoding typeof(nil) in the test.
This should partially fix the linux bot. There is still one assertion
failure remaining, which I'll have to investigate separately, as I am
not experiencing it locally.
llvm-svn: 328083
|
|
|
|
|
|
|
|
| |
New tests should run the make syntax voodoo $@ and $<
instead of hardcoding the names. We should also document
how to write one, it's on my list.
llvm-svn: 328062
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of applying the sledgehammer of refusing to insert any
C++ symbol in the ASTContext, try to validate the decl if what
we have is an operator. There was other code in lldb which was
responsible for this, just not really exposed (or used) in this
codepath. Also, add a better/more comprehensive test.
<rdar://problem/35645893>
llvm-svn: 328025
|
|
|
|
|
|
|
|
| |
If we don't wrap arguments to the wrapper in single quotes, combined
arguments, for example for -E, don't reach dotest.py as a unit but as
separate arguments, causing the latter to fail.
llvm-svn: 328020
|
|
|
|
| |
llvm-svn: 328013
|
|
|
|
|
|
|
|
| |
While trying to use this header I noticed that it is not in the include
folder. Move it to there and update all #includes to reference that file
correctly.
llvm-svn: 327996
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When running on an architecture other than x86_64, the
target.ConnectRemote() part of the test may add platform information to
the target triple.
It was observed that this happens at Process::CompleteAttach() method,
after the platform_sp->IsCompatibleArchitecture() check fails.
This method then calls platform_sp->GetPlatformForArchitecture(), that
on a Linux machine ends up returning a generic Linux platform, that then
ends up getting added to the original target architecture.
Reviewers: clayborg, labath, jasonmolenda
Reviewed By: labath
Subscribers: alexandreyy, lbianc
Differential Revision: https://reviews.llvm.org/D44022
Patch by Leandro Lupori <leandro.lupori@gmail.com>.
llvm-svn: 327981
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Fix test jump for powerpc64le
Jumping directly to the return line on power architecture dos not means
returning the value that is seen on the code. The last test fails, because
it needs the execution of some assembly in the beginning of the function.
Avoiding this test for this architecture.
- Avoid evaluate environ variable name on Linux
On Linux the Symbol environ conflicts with another variable, then in
order to avoid it, this test was moved into a specific test, which is not
supported if the OS is Linux.
- Added PPC64le as MIPS behavior
Checking the disassembler output, on PPC64le machines behaves as MPIS.
Added method to identify PPC64le architecture and checking it when
disassembling instructions in the test case.
Reviewers: labath
Reviewed By: labath
Subscribers: clayborg, labath, luporl, alexandreyy, sdardis, ki.stfu, arichardson
Differential Revision: https://reviews.llvm.org/D44101
Patch by Leonardo Bianconi <leonardo.bianconi@eldorado.org.br>.
llvm-svn: 327977
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
regions
The difference between this and the previous patch is that now we use
ELF physical addresses only for loading objects into the target (and the
rest of the module load address logic still uses virtual addresses).
Summary:
When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup.
- Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address.
- Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications
- Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region
Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html
Reviewers: clayborg, labath
Reviewed By: labath
Subscribers: llvm-commits, arichardson, emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D42145
Patch by Owen Shaw <llvm@owenpshaw.net>.
llvm-svn: 327970
|
|
|
|
| |
llvm-svn: 327941
|
|
|
|
| |
llvm-svn: 327927
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Replace SymbolFilePDB::GetSourceFileNameForPDBCompiland() with PDBSymbolCompiland::getSourceFileFullPath().
Reviewers: zturner, rnk, lldb-commits
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44456
llvm-svn: 327925
|
|
|
|
| |
llvm-svn: 327924
|
|
|
|
|
|
|
|
|
| |
to com.apple.internal.xpc.remote.debugserver.plist, not sure where
that remotectl_ prefix came from.
<rdar://problem/36751222>
llvm-svn: 327922
|
|
|
|
|
|
|
|
| |
in to debugserver; my re-addition resulted in duplicated
symbols. Remove my added SocketAddress.cpp, and change the
original one to also be included for the debugserver-mini target.
llvm-svn: 327918
|
|
|
|
|
|
|
|
| |
the debugserver-mini target in debugserver. Add a new plist
which needs to be installed for debugserver-mini.
<rdar://problem/36751222>
llvm-svn: 327915
|
|
|
|
| |
llvm-svn: 327913
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: zturner, rnk, lldb-commits
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44455
llvm-svn: 327908
|
|
|
|
|
|
| |
These tests tend to time out locally and on our bots.
llvm-svn: 327906
|
|
|
|
|
|
|
|
| |
These tests do not pass/fail consistently, so just skip them.
This is llvm.org/pr15824 & rdar://problem/28557237.
llvm-svn: 327905
|
|
|
|
| |
llvm-svn: 327893
|
|
|
|
|
|
| |
This should address a bot failure due to r327809.
llvm-svn: 327865
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now the codebase can use the DWARFUnit superclass. It will make it later
seamlessly work also with DWARFPartialUnit for DWZ.
This patch is only a search-and-replace easily undone, nothing interesting
in it.
Differential revision: https://reviews.llvm.org/D42892
llvm-svn: 327810
|
|
|
|
|
|
|
|
|
| |
DW_TAG_partial_unit for DWZ can be then presented by DWARFPartialUnit also
inherited from DWARFUnit.
Differential revision: https://reviews.llvm.org/D40466
llvm-svn: 327809
|
|
|
|
| |
llvm-svn: 327753
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
decl context.
Summary:
When in a gmodules-like debugging scenario, you can have a parent decl context
that gets imported from an external AST. When this happens, we must be careful
to complete this type before adding children to it, otherwise it sometimes
results in a crash.
Reviewers: clayborg, jingham
Subscribers: aprantl, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D43592
llvm-svn: 327750
|
|
|
|
|
|
| |
Bot failure: https://ci.swift.org/job/oss-lldb-incremental-osx/1104/
llvm-svn: 327731
|
|
|
|
| |
llvm-svn: 327729
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch implements a unified way of cleaning the build folder of each
test. This is done by completely removing the build folder before each
test, in the respective setUp() method. Previously, we were using a
combination of several methods, each with it's own drawbacks:
- nuking the entire build tree before running dotest: the issue here is
that this did not take place if you ran dotest manually
- running "make clean" before the main "make" target: this relied on the
clean command being correctly implemented. This was usually true, but
not always.
- for files which were not produced by make, each python file was
responsible for ensuring their deleting, using a variety of methods.
With this approach, the previous methods become redundant. I remove the
first two, since they are centralized. For the other various bits of
clean-up code in python files, I indend to delete it when I come
across it.
Reviewers: aprantl
Subscribers: emaste, ki.stfu, mgorny, eraman, lldb-commits
Differential Revision: https://reviews.llvm.org/D44526
llvm-svn: 327703
|
|
|
|
|
|
| |
Bot failure: https://ci.swift.org/job/oss-lldb-incremental-osx/1097/testReport/junit/TestMiTarget/MiTargetTestCase/test_lldbmi_target_attach_wait_for/
llvm-svn: 327692
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
are installed
Instead of building debugserver when building lldb, I'd rather pass
LLDB_CODESIGN_IDENTITY="" to cmake and use the one already on my system.
However, on one of my machines I only have the CommandLineTools installed, and
so the hardcoded path to the system debugserver does not work for me.
Additionally, we should verify the LLDB framework exists on the machine before
trying to set the path to debugserver. This allows us to warn the user at
configure time that a system debugserver can't be found if they choose not to
build it themselves.
Patch by Alex Langford!
Differential Revision: https://reviews.llvm.org/D44507
llvm-svn: 327691
|
|
|
|
| |
llvm-svn: 327644
|