ExprCommandWithTimeoutsTestCase::expectedFailureFreeBSD
This test passes locally but was marked XFAIL due to failures on the
FreeBSD buildbot. That buildbot has been retired as it was overloaded,
and we will investigate again if this fails once a new buildbot is in
place.
llvm.org/pr19605
llvm-svn: 247799
Split-dwarf uses a different header format to specify the address range
for the elements of the location lists.
Differential revision: http://reviews.llvm.org/D12880
llvm-svn: 247789
GCC don't use the is_prologue_end flag to mark the first instruction
after the prologue. Instead of it it is issuing a line table entry for
the first instruction of the prologue and one for the first instruction
after the prologue. If the size of the prologue is 0 instruction then
the 2 line entry will have the same file address.
We remove these duplicates entries as they are violating the dwarf spec
and can cause confusion in the debugger. To prevent the lost of
information about the end of prologue we should set the prologue end
flag for the line entries what are representing more then 1 entry.
Differential revision: http://reviews.llvm.org/D12757
llvm-svn: 247788
Use Breakpoint::AddName to mark all RenderScript kernel breakpoints with the name 'RenderScriptKernel'.
Also update logging channels to include LIBLLDB_LOG_BREAKPOINT where appropriate.
llvm-svn: 247782
SUMMARY:
Refer to http://lists.llvm.org/pipermail/lldb-dev/2015-August/008024.html for discussion
on this topic. Bare-iron target like YAMON gdb-stub does not support qProcessInfo, qC,
qfThreadInfo, Hg and Hc packets. Reply from ? packet is as simple as S05. There is no
packet which gives us process or threads information. In such cases, assume pid=tid=1.
Reviewers: clayborg
Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits
Differential Revision: http://reviews.llvm.org/D12876
llvm-svn: 247773
debugserver to match. "gcc" is now "ehframe" and "gdb" is now
"debugserver". Because this is debugserver, what we call the Process
Plugin register numbers up in lldb are the debugserver register
numbers down here - they are the register numbers that debugserver
will use to refer to these registers over the gdb-remote protocol.
debugserver was already reporting the registers with the key
"ehframe"; this change is just cleaning up the internal variable
names to match.
llvm-svn: 247751
Summary: SymbolFileDWARF now creates VarDecl and BlockDecl and adds them to the Decl tree. Then, in ClangExpressionDeclMap it uses the Decl tree to search for a variable. This fixes lots of variable scoping problems.
Reviewers: sivachandra, chaoren, spyffe, clayborg
Subscribers: tberghammer, jingham, lldb-commits
Differential Revision: http://reviews.llvm.org/D12658
llvm-svn: 247746
"gcc" register numbers are now correctly referred to as "ehframe"
register numbers. In almost all cases, ehframe and dwarf register
numbers are identical (the one exception is i386 darwin where ehframe
regnums were incorrect).
The old "gdb" register numbers, which I incorrectly thought were
stabs register numbers, are now referred to as "Process Plugin"
register numbers. This is the register numbering scheme that the
remote process controller stub (lldb-server, gdbserver, core file
support, kdp server, remote jtag devices, etc) uses to refer to the
registers. The process plugin register numbers may not be contiguous
- there are remote jtag devices that have gaps in their register
numbering schemes.
I removed all of the enums for "gdb" register numbers that we had
in lldb - these were meaningless - and I put LLDB_INVALID_REGNUM
in all of the register tables for the Process Plugin regnum slot.
This change is almost entirely mechnical; the one actual change in
here is to ProcessGDBRemote.cpp's ParseRegisters() which parses the
qXfer:features:read:target.xml response. As it parses register
definitions from the xml, it will assign sequential numbers as the
eRegisterKindLLDB numbers (the lldb register numberings must be
sequential, without any gaps) and if the xml file specifies register
numbers, those will be used as the eRegisterKindProcessPlugin
register numbers (and those may have gaps). A J-Link jtag device's
target.xml does contain a gap in register numbers, and it only
specifies the register numbers for the registers after that gap.
The device supports many different ARM boards and probably selects
different part of its register file as appropriate.
http://reviews.llvm.org/D12791
<rdar://problem/22623262>
llvm-svn: 247741
Before we had:
ClangFunction
ClangUtilityFunction
ClangUserExpression
and code all over in lldb that explicitly made Clang-based expressions. This patch adds an Expression
base class, and three pure virtual implementations for the Expression kinds:
FunctionCaller
UtilityFunction
UserExpression
You can request one of these expression types from the Target using the Get<ExpressionType>ForLanguage.
The Target will then consult all the registered TypeSystem plugins, and if the type system that matches
the language can make an expression of that kind, it will do so and return it.
Because all of the real expression types need to communicate with their ExpressionParser in a uniform way,
I also added a ExpressionTypeSystemHelper class that expressions generically can vend, and a ClangExpressionHelper
that encapsulates the operations that the ClangExpressionParser needs to perform on the ClangExpression types.
Then each of the Clang* expression kinds constructs the appropriate helper to do what it needs.
The patch also fixes a wart in the UtilityFunction that to use it you had to create a parallel FunctionCaller
to actually call the function made by the UtilityFunction. Now the UtilityFunction can be asked to vend a
FunctionCaller that will run its function. This cleaned up a lot of boiler plate code using UtilityFunctions.
Note, in this patch all the expression types explicitly depend on the LLVM JIT and IR, and all the common
JIT running code is in the FunctionCaller etc base classes. At some point we could also abstract that dependency
but I don't see us adding another back end in the near term, so I'll leave that exercise till it is actually necessary.
llvm-svn: 247720
Summary:
CMICmdArgSet stores a vector of non-const pointers to the arguments
that it is validating. It owns them and is responsible for deleting
them.
We don't need to pass a const reference to the argument to
CMICmdArgSet::Add and then take the address and const_cast it
when we can just pass the argument pointer in directly.
This lets us remove some noise at every call site for CMICmdArgSet::Add
and then clean up a couple of bits inside CMICmdArgSet to remove
const_casts.
Reviewers: abidh, ki.stfu, domipheus
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12878
llvm-svn: 247677
Summary:
* SharedDataDestroy couldn't fail, so no need to return a status.
* No need for status, so can remove error message. The error message
wasn't displayed or used anywhere anyway.
Reviewers: abidh, ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12879
llvm-svn: 247673
SUMMARY:
This patch provides support for MIPS specific DT_MIPS_RLD_MAP_REL tag in LLDB.
This tag allows debugging of MIPS position independent executables and provides access to shared library information.
Reviewers: clayborg
Subscribers: mohit.bhakkad, sagar, jaydeep, lldb-commits
Differential Revision: http://reviews.llvm.org/D12794
llvm-svn: 247666
Marked XFAIL for:
clang - all versions < 3.5. I verified the first version it passes on Linux is 3.5.
clang - version 3.7 (verified this fails)
clang - TOT/3.8 (verified this currently fails)
Ideally we dig into why this started failing and (hopefully) get this passing again.
llvm-svn: 247664
Summary:
This was int64_t, but all usages of it came from code that was passing
in unsigned values. The usages of the array size, except for one, were
also treating it as an unsigned value. The usage that treated it as
signed was to try to figure out if it was a complete type or not, but
the callers creating the array didn't seem to be aware of using -1 as
an indicator for an incomplete array.
Reviewers: ribrdb, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12872
llvm-svn: 247662
Summary:
Linux with ToT clang (3.8) fails.
This reverts commit r247633.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12868
llvm-svn: 247648
c:\buildbot\lldb-windows-x86\lldb-windows-x86\llvm\tools\lldb\source\symbol\goastcontext.cpp(906) : warning C4715: 'lldb_private::GoASTContext::GetBitSize' : not all control paths return a value
c:\buildbot\lldb-windows-x86\lldb-windows-x86\llvm\tools\lldb\source\symbol\goastcontext.cpp(1175) : error C4716: 'lldb_private::GoASTContext::ConvertStringToFloatValue' : must return a value
llvm-svn: 247647
Linux/clang on clang 3.6+ is passing this test. As OS X was
in a similar position, I'm guessing this was fixed by a recent
compiler. Might work on 3.5/3.4, but it is definitely working
on clang 3.6. I didn't break out FreeBSD since this appears to
be related to a compiler fix.
llvm-svn: 247633
TestPersistObjCPointeeType and TestObjCNewSyntax marked up to expect
success on clang >= 7.0.0.
TestMultipleDebuggers passed 25/25 times, taking off intermittent.
If this changes, I'll make sure it goes into a flaky/flakey category.
llvm-svn: 247601
Summary:
Linux and FreeBSD occasionally send SI_KERNEL codes, nonexistent on other platforms.
Problem caught on NetBSD.
Reviewers: joerg, sas
Subscribers: sas, lldb-commits, emaste
Differential Revision: http://reviews.llvm.org/D12659
Change by Kamil Rytarowski <n54@gmx.com>
llvm-svn: 247579
The iterator pointing to an element of a dense map was used after
the element from was removed from the map what isn't guaranteed to be
valid at that time.
llvm-svn: 247571
Related to these two test case classes:
test/driver/batch_mode/TestBatchMode.py
test/functionalities/inferior-assert/TestInferiorAssert.py
llvm-svn: 247567
This test passes locally but was disabled due to pexpect issues on the
FreeBSD buildbot. That buildbot has been retired as it was overloaded,
and we will investigate again if this fails once a new buildbot is in
place. Noted by John Wolfe.
llvm.org/pr22784
This re-applies r247013.
llvm-svn: 247565
This test passes locally but was marked XFAIL due to failures on the
FreeBSD buildbot. That buildbot has been retired as it was overloaded,
and we will investigate again if this fails once a new buildbot is in
place.
llvm.org/pr23747
llvm-svn: 247562
RegisterContextPOSIX.h is poorly named and contains only the declaration
of POSIXBreakpointProtocol, which is used for in-process live kernel
debugging. It is now relevant only to FreeBSD.
In source/Plugins/Process/Utility/RegisterContext*.h (after assorted
rework and refactoring) it only served the purpose of #including other
necessary headers as a side-effect. Remove it from them and just include
the required headers directly.
Differential Revision: http://reviews.llvm.org/D12830
llvm-svn: 247558
Summary:
Realtime signals generally do not represent an error condition in an application but are more
like a regular means of IPC. As such, we shouldn't interrupt an application whenever it recieves
one. If any application will use these signals, it will probably use them a lot, rendering it's
debugging tiresome if we stopped at every signal. Furthermore, these signals are likely to be used
in a low level library, and the programmer may not even be aware of their presence.
For these reasons, I am switching the default disposition of realtime signals on all supported
platforms (i.e. Linux and Freebsd) to no-stop, no-notify. Any user still wishing to receive these
signals can always change the default to suit his needs.
Reviewers: ovyalov, emaste
Subscribers: lldb-commits, emaste
Differential Revision: http://reviews.llvm.org/D12795
llvm-svn: 247537
This is a trivial issue to fix, just marking it for later.
Windows prints function signatures a bit differently, and the
test expects a specific format.
llvm-svn: 247457
Summary:
There's no need to call CMIUtilString::Format
with a string and no args.
Reviewers: abidh, ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12796
llvm-svn: 247403
Summary:
This builds on all platforms, so remove duplication in build
configuration.
Reviewers: labath, clayborg, emaste
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12792
llvm-svn: 247402
Change the mapping symbol handling to handle the case when the mapping
symbols are prefixed with an arbitrary prefix. This isn't strictly standard
compliance, but if all symbols in an object file is prefixed with objcopy
then the prefix will be added to the mapping symbol also. We still want to
treat these symbols as mapping symbols to get the correct address class data.
Differential revision: http://reviews.llvm.org/D12755
llvm-svn: 247400
Summary:
This platform-specific code wasn't fully implemented and wasn't
actually needed. There was one call for the log file path and
that has been addressed.
This lets us also remove an error message from MICmnLogMediumFile
as it is no longer used.
Reviewers: ki.stfu, domipheus, abidh
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12764
llvm-svn: 247388
Summary:
* cmake/LLDBDependencies.cmake: elf-core is already included
globally in LLDB_USED_LIBS, so it doesn't need to be re-added
on individual platforms.
* lib/Makefile: elf-core is linked on each platform, so move it
to the global list of used libraries.
* source/Plugins/Makefile: elf-core is built on each platform, so
move it to the global list of things to build.
Reviewers: clayborg, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12762
llvm-svn: 247366
Summary:
We currently link to this on all platforms, so don't need to re-include
it into the LLDB_USED_LIBS. Also don't need to special case building
it for every supported platform.
Reviewers: clayborg, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12756
llvm-svn: 247284
Patch adds a command to RenderScript plugin allowing users to automatically set breakpoints on every RS kernel.
Command syntax is 'language renderscript kernel breakpoint all <enable/disable>.'
Enable sets breakpoints on all currently loaded kernels, and any kernels which will be loaded in future.
Disable results in breakpoints no longer being set on loaded kernels, but doesn't affect existing breakpoints.
Current command 'language renderscript kernel breakpoint' is changed to 'language renderscript kernel breakpoint set'
Reviewed by: clayborg, jingham
Subscribers: lldb-commits, ADodds, domipheus
Differential Revision: http://reviews.llvm.org/D12728
llvm-svn: 247262
This patch fixes the following case:
```
$ ./dotest.py --executable=~/p/llvm/build_ninja/bin/lldb tools/lldb-mi/
'~/p/llvm/build_ninja/bin/lldb' is not a path to a valid executable
Traceback (most recent call last):
File "./dotest.py", line 1306, in <module>
setupSysPath()
File "./dotest.py", line 1004, in setupSysPath
if not lldbtest_config.lldbExec:
AttributeError: 'module' object has no attribute 'lldbExec'
```
And with this fix:
```
$ ./dotest.py --executable=~/p/llvm/build_ninja/bin/lldb tools/lldb-mi/
'~/p/llvm/build_ninja/bin/lldb' is not a path to a valid executable
The 'lldb' executable cannot be located. Some of the tests may not be run as a result.
```
llvm-svn: 247256
I was experimenting with it briefly, and then settled on Target::GetTypeSystem + TypeSystem::GetBasicType, so this API is not necessary to have
Thanks to Ryan Brown for bringing it to my attention
llvm-svn: 247195
It often hangs or times out, and obscures issues with other tests.
Just skip it for now (until the FreeBSD test suite is producing
consistent results) so that we can get a buildbot back.
Previous investigation (for failures) in llvm.org/pr18522
llvm-svn: 247190
We had 2 tests named TestCPPBreakpoints.py. If one of those tests
failed, both of them would be reported as failures and contribute
to the failure count. There may be other examples of duplicate
test names, and we should fix those as we find them.
llvm-svn: 247173
In some special case (e.g. signal handlers, hand written assembly) it is
valid to have 2 stack frame with the same CFA value. This CL change the
looping stack detection code to report a loop only if at least 3
consecutive frames have the same CFA.
Differential revision: http://reviews.llvm.org/D12699
llvm-svn: 247133
* Create new dwo symbol file class
* Add handling for .dwo sections
* Change indexes in SymbolFileDWARF to store compile unit offset next to
DIE offset
* Propagate queries from dwarf compile unit to the dwo compile unit
where applicable
Differential revision: http://reviews.llvm.org/D12291
llvm-svn: 247132
* Remove some unused code
* Remove usage of DWARFDebugInfoEntry::Attributes where usage isn't
reasonable
* Cleanup DWARFMappedHash with separating it to header and implementation
file and fixing the visibility of the functions
Differential revision: http://reviews.llvm.org/D12374
llvm-svn: 247131
Summary:
When lldb is processing a location containing DW_OP_piece, the result is being
stored in the 'pieces' variable. The location is popped from the 'stack' variable.
So this check to see that 'stack' is not empty was invalid and caused the pieces
after the first to not get processed.
I am working on an architecture which has 16-bit and 8-bit registers. So this
problem was quite easy to see. But I was able to re-produce this issue on x86
too with long long variable and compiling woth -m32. It resulted in following
location list.
00000014 08048496 080484b5 (DW_OP_reg6 (esi); DW_OP_piece: 4; DW_OP_reg7 (edi); DW_OP_piece: 4)
and lldb was only showing the contents of first register when I evaluated the
variable as it does not process the 2nd piece due to this check.
Reviewers: clayborg, aprantl
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12674
llvm-svn: 247124
qXfer:features:read:target.xml packet, or via the
plugin.process.gdb-remote.target-definition-file setting, if the
register definition doesn't give us eh_frame or DWARF register
numbers for that register, try to get that information from the ABI
plugin.
The DWARF/eh_frame register numbers are defined in the ABI
standardization documents - so getting this from the ABI plugin is
reasonable. There's little value in having the remote stub inform
us of this generic information, as long as we can all agree on the
names of the registers.
There's some additional information we could get from the ABI. For
instance, on ABIs where function arguments are passed in registers,
lldb defines alternate names like "arg1", "arg2", "arg3" for these
registers so they can be referred to that way by the user. We could
get this from the ABI if the remote stub doesn't provide that. That
may be something worth doing in the future - but for now, I'm keeping
this a little more minimal.
Thinking about this, what we want/need from the remote stub at a
minimum are:
1. The names of the register
2. The number that the stub will use to refer to the register with
the p/P packets and in the ? response packets (T/S) where
expedited register values are provided
3. The size of the register in bytes
(nice to have, to remove any doubt)
4. The offset of the register in the g/G packet if we're going to
use that for reading/writing registers.
debugserver traditionally provides a lot more information in
addition to this via the qRegisterInfo packet, and debugserver
augments its response to the qXfer:features:read:target.xml
query to include this information. Including:
DWARF regnum, eh_frame regnum, stabs regnum, encoding (ieee754,
Uint, Vector, Sint), format (hex, unsigned, pointer, vectorof*,
float), registers that should be marked as invalid if this
register is modified, and registers that contain this register.
We might want to get all of this from the ABI - I'm not convinced
that it makes sense for the remote stub to provide any of these
details, as long as the ABI and remote stub can agree on register
names.
Anyway, start with eh_frame and DWARF coming from the ABI if
they're not provided by the remote stub. We can look at doing
more in the future.
<rdar://problem/22566585>
llvm-svn: 247121
When lldb receives a gdb-remote protocol packet that has
nonprintable characters, it will print the packet in
gdb-remote logging with binary-hex encoding so we don't
dump random 8-bit characters into the packet log.
I'm changing this check to allow whitespace characters
(newlines, linefeeds, tabs) to be printed if those are
the only non-printable characters in the packet.
This is primarily to get the response to the
qXfer:features:read:target.xml packet to show up in the
packet logs in human readable form. Right now we just
get a dozen kilobytes of hex-ascii and it's hard to
figure out what register number scheme is being used.
llvm-svn: 247120
This used to be hardcoded in the FormatManager, but in a pluginized world that is not the right way to go
So, move this step to the Language plugin such that appropriate language plugins for a type get a say about adding candidates to the formatters lookup tables
llvm-svn: 247112
Summary:
The format string was not set up correctly as it was missing the %.
This resulted in a warning (correctly) that the data arguments were
not all used.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12714
llvm-svn: 247111
See https://llvm.org/bugs/show_bug.cgi?id=24708 for details.
Using '-f FILTER' or unnamed arguments (directories) to dotest.py
will now force no-multiprocessing mode. This stops a bombardment
of test output spam when following the instructions we provide
in a test session trace for rerunning the test.
llvm-svn: 247101
As part of our overall switch from hand-rolling RTTI to using LLVM-compatible
methods, I've done the same for ExpressionVariable. The main documentation for
how to do this is in TypeSystem.h, so I've simply referred to that.
llvm-svn: 247085
This will keep our code cleaner and it removes the need for intrusive additions to TypeSystem like:
class TypeSystem
{
virtual ClangASTContext *
AsClangASTContext() = 0;
}
As you can now just use the llvm::dyn_cast and other casts.
llvm-svn: 247041
Summary: Problem was caught on NetBSD.
Reviewers: joerg, sas
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12654
Change by Kamil Rytarowski <n54@gmx.com>
llvm-svn: 247034
And update the comment describing the reason this test is skipped.
Unlike the issue described llvm.org/pr22784 this test sometimes causes
a hang on my local machine and is not just a problem on the retired
buildbot.
This reverts commit r247013.
llvm-svn: 247024
This test passes locally but was disabled due to pexpect issues on the
FreeBSD buildbot. That buildbot has been retired as it was overloaded,
and we will investigate again if this fails once a new buildbot is in
place. Noted by John Wolfe.
llvm.org/pr22784
llvm-svn: 247013
Summary:
- Bug 24457 can now be tested for inferiors compiled
by clang compiler also.
- A generic test case for GCC and Clang inferiors:
-- Works even when Clang and GCC produce different
assembly for the same inferior.
- Refer Differential Revision: http://reviews.llvm.org/D12677
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
llvm-svn: 247000
Summary:
This should be a mandatory build process going forward, if Python
is enabled. The longer term desire is to remove the old shell
scripts entirely.
Reviewers: zturner, clayborg, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12667
llvm-svn: 246979
Summary:
For an array declared like "blk[2][3]", this command was showing:
-data-evaluate-expression blk
^done,value="{[0] = [3], [1] = [3]}"
After this fix, it shows:
-data-evaluate-expression blk
^done,value="{[0] = {[0] = 1, [1] = 2, [2] = 3}, [1] = {[0] = 4, [1] = 5, [2] = 6}}"
The code to do the right thing was already available and used by other commands.
So I have just used that and removed the half-baked previous implementation.
Reviewers: ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12634
llvm-svn: 246965
It is required because of the following edge case on arm:
bx <addr> Non-tail call in a no return function
[data-pool] Marked with $d mapping symbol
The return address of the function call will point to the data pool but
we have to treat it as code so the StackFrame can calculate the symbols
correctly.
Differential revision: http://reviews.llvm.org/D12556
llvm-svn: 246958
- clang is picky about inline assembly: add the correct instruction size suffix
- mark the new test as expectedFailureClang: the test fails as the breakpoint is set in the wrong
place
llvm-svn: 246957
Summary:
- For 'register read --all' command on x86_64-Linux Platform:
-- Provide correct values of X87 FPU Special Purpose Registers
-- Both 32-bit & 64-bit inferiors give correct values on this
Platform
- Added a Test Vector:
-- To verify the expected behaviour of the command
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: ashok.thirumurthi, granata.enrico, tfiala, clayborg
Differential Revision: http://reviews.llvm.org/D12592
llvm-svn: 246955
Summary: lldb::tid_t is 64 bit, but "long" need not always be 64 bit.
Reviewers: chying, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12650
llvm-svn: 246885
stores information about a variable that different parts of LLDB use, from the
compiler-specific portion that only the expression parser cares about.
http://reviews.llvm.org/D12602
llvm-svn: 246871
The call to ProcessWindowsLog::Initialize() is protected by #if defined(_MSC_VER).
But the call to ProcessWindowsLog::Terminate() was using __WIN32__. This commit
makes it use _MSC_VER too.
Committing as it seems obvious change.
llvm-svn: 246859
* Change Module::MatchesModuleSpec to return true in case the file spec
in the specified module spec matches with the platform file spec, but
not with the local file spec
* Change the module_resolver used when resolving a remote shared module
to always set the platform file spec to the file spec requested
Differential revision: http://reviews.llvm.org/D12601
llvm-svn: 246852
1. To handle the expression with spaces, this command uses 2 arguments. For a case
like -break-condition 1 i == 5, the first will pick the 'i' and second will
pick the '== 5'. But the second argument was made mandatory which failed in
cases when there was no space in the expression like i==5.
2. The function GetRestOfExpressionNotSurroundedInQuotes has 2 locals with the
same names. It resulted in one hiding the other and this function always
returned empty string.
No regression on Linux. Committed as obvious.
llvm-svn: 246847
Summary:
GetOptInc provides getopt(), getopt_long() and getopt_long_only().
Windows (for defined(_MSC_VER)) doesn't ship with all of the getopt(3) family members and needs all of them. NetBSD requires only getopt_long_only(3).
While there fix the code for clang diagnostics.
Author: Kamil Rytarowski
Reviewers: joerg
Subscribers: labath, zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D12582
llvm-svn: 246843
Currently the RS breakpoint command can only find a kernel if it's in an already loaded RS module.
This patch allows users to set pending breakpoints on RenderScript kernels which will be loaded in the future.
Implemented by creating a RS breakpoint resolver, to limit search scope to only RS modules.
Reviewed by: clayborg, jingham
Subscribers: lldb-commits, ADodds, domipheus
Differential Revision: http://reviews.llvm.org/D12360
llvm-svn: 246842
Summary:
- Capability to force return user specified values
from inside of a function on lldb command terminal
- Support for Integral, Pointer and Floating Point values
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: jingham, clayborg
Subscribers: tberghammer
Differential Revision: http://reviews.llvm.org/D12595
llvm-svn: 246841
ehframe_ & from gdb_ to stabs_ for clarity.
Also document the fact that i386 eh_frame on Darwin has the register
numbers swapped for ebp/esp from the DWARF register numbers so no one
copies these defines for other i386 ABI plugins. This bug only ever
existed on Darwin.
No code changes, just renaming variables.
llvm-svn: 246834
* Use the frame's context (instead of just the target's) when evaluating,
so that the language of the frame's CU can be used to select the
compiler and/or compiler options to use when parsing the expression.
This allows for modules built with mixed languages to be parsed in
the context of their frame.
* Add all C and C++ language variants when determining the language options
to set.
* Enable C++ language options when language is C or ObjC as a workaround since
the expression parser uses features of C++ to capture values.
* Enable ObjC language options when language is C++ as a workaround for ObjC
requirements.
* Disable C++11 language options when language is C++03.
* Add test TestMixedLanguages.py to check that the language being used
for evaluation is that of the frame.
* Fix test TestExprOptions.py to check for C++11 instead of C++ since C++ has
to be enabled for C, and remove redundant expr --language test for ObjC.
* Fix TestPersistentPtrUpdate.py to not require C++11 in C.
Reviewed by: clayborg, spyffe, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11102
llvm-svn: 246829
Summary:
This also moves the xcode support files to be near or the same
as the ones used for cmake.
The source/API/liblldb.xcodes.exports differs from the
source/API/liblldb.exports in that one contains the actual
symbol names (_ prefixed) while the other contains the symbol
names as they are in the code. The liblldb.exports file is
preprocessed by the cmake scripts into the correct per-platform
file needed (like a linker script on Linux).
This is not enabled on Windows as Windows doesn't use the same
name mangling and so it won't be valid there. Also, this is handled
already in a different way on Windows (via dll exports).
Reviewers: emaste, clayborg, labath, chaoren
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12599
llvm-svn: 246822
Summary:
The AppleGetQueuesHandler code no longer needs to include a header
from the AppleObjCRuntime, so we can remove workarounds that were
present in the build systems.
Reviewers: clayborg, jasonmolenda
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12589
llvm-svn: 246821
Summary:
There was a race condition in the AsyncThread, where we would end up sending a vAttach
notification to the thread before it got a chance set up its listener (this can be reproduced by
adding a sleep() at the very beginning of ProcessGDBRemote::AsyncThread()). This event would then
get lost and we LLDB would deadlock. I fix this by setting up the listener early on, in the
ProcessGDBRemote constructor.
This should improve the stability of all attach tests. For now, I am removing XTIMEOUT from
TestAttachResume, and will watch the buildbots for signs of trouble.
Reviewers: clayborg, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12552
llvm-svn: 246756
Summary:
There was a race condition in Process class, where we would not wait for process stdout to
propagate fully before we would shut down the connection (repro case: slow down the stdio thread
by placing a sleep right at the end of the while loop in Communication::ReadThread). The Process
class already tried to solve this problem by synchronizing with the read thread in
Process::ShouldBroadcastEvent, but unfortunately the connection got closed before that in
Process::SetExitStatus. I solve this issue by delaying the connection shutdown until we get a
chance to process the event and synchronize. Alternatively, I could have moved the
synchronization point to an earlier point in SetExitStatus, but it seems safer to delay the
shutdown until other things get a chance to notice the process has exited.
Reviewers: clayborg, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12558
llvm-svn: 246753
Summary:
This doesn't exist in other LLVM projects any longer and doesn't
do anything.
Reviewers: chaoren, labath
Subscribers: emaste, tberghammer, lldb-commits, danalbert
Differential Revision: http://reviews.llvm.org/D12586
llvm-svn: 246749
almost all the elements on the list can't actually be passed to the language
command and all the ones that can have already been listed in the subcommands
list.
<rdar://problem/22551082>
llvm-svn: 246740
This is still something I need to fix, but at least it's not so ugly, and it's
consistent with the other code that does that so we will catch it when we purge
all such code.
llvm-svn: 246738
Clang-specific part, create the ExpressionVariable source/header file and
move ClangExpressionVariable into the Clang expression parser plugin.
It is expected that there are some ugly #include paths... these will be resolved
by either (1) making that code use generic expression variables (once they're
separated appropriately) or (2) moving that code into a plug-in, often
the expression parser plug-in.
llvm-svn: 246737
Some tests were failing because the test would try to delete the
file before inferior had exited, but on Windows this will fail by
default unless you specify FILE_SHARE_DELETE when opening the file.
Can't think of a good reason not to do this, so here it is.
llvm-svn: 246682
Instead of fixing these tests by finding a pexpect replacement,
this set of tests can be fixed by re-writing the test to not use
pexpect.
llvm.org/pr24679
llvm-svn: 246671
This fixes a regression caused by r245645 where creating alternative
thumb disassembler was enabled even when the main disassembler is
already thumb.
llvm-svn: 246649
If no architecture is defined for the disassambler command then it uses
the architecture of the target. In case of arm it will be "arm" what is
treated as the oldest arm version by the LLVM disassambler causing a lot
of invalid opcode in the output.
This change forces the use of "armv8.1a" (the newest arm architecture) if
no sub architecure was specified (either by the user or by the target) to
disassamble all instruction.
Differential revision: http://reviews.llvm.org/D12553
llvm-svn: 246648
If a command argument contains a space then it have to be escaped with
backslash signs so the argument parsing logic can parse it properly.
This CL fixes the tab completion code for the arguments to create
complitions with correctly escaped strings.
Differential revision: http://reviews.llvm.org/D12531
llvm-svn: 246639
Summary:
The test (among other things) attempts to verify that detaching works while the inferior is
running. However, this was racy since the inferior could end up stopping again before we got a
chance to detach from it (the test could be made to fail reliably by inserting a sleep just after
the last "continue" command). The reason for the stop was that we had a breakpoint set in a place
that can be hit by multiple threads, and we stop because another thread hit a breakpoint.
I fix this by moving the breakpoint to a place that is reachable from only one thread. I also
make sure that the same thread cannot hit the breakpoint if we are exceptionaly slow by flipping
a flag which makes the breakpoint unreachable (I cannot just disable or delete the breakpoint as
the test makes it a point to try detaching while breakpoints are still set).
Another source or racyness was that the test verified that the process resumes and
stops after a "continue". However, if these two events happened too fast, the initial start event
would be lost, and the test would end up confused. I have implemented this in a safer manner and
made a utility function out of it, as I know of a couple of other tests which need the same
functionality.
Reviewers: zturner, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12527
llvm-svn: 246623
These are useful helpers over the low-level API of the FormattersContainer, and since we're actually going to start moving formatters into plugins, it makes sense to simplify things
llvm-svn: 246612
Summary:
When calling find_first_of and find_last_of on a single character,
we can instead just call find / rfind and make our intent more
clear.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12518
llvm-svn: 246609
Summary:
This was removed from the other ABI plugins long ago. This removes
a warning that was happening in this unused code as a result of
adding 2 new types to Scalar.h (e_uint128 and e_sint128).
Reviewers: clayborg
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12514
llvm-svn: 246608
Summary:
Comparing m_page_size against kInvalidPageSize was resulting in
a warning about comparing integers with different signs. Since
kInvalidPageSize isn't used anywhere outside of MachVMMemory.cpp,
we can readily transform it into a static const vm_size_t with
the correct value to avoid the sign comparison warnings.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12519
llvm-svn: 246606
Summary:
This was previously only established within debugserver, but
there is a use of the VLA extension in source/Host/macosx/Symbols.cpp,
so ignore this warning globally.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12515
llvm-svn: 246605
Historically, data formatters all exist in a global repository (the category map)
On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex)
This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on
The advantages of this are:
a) language formatters only get created when they might apply
b) formatters for a language are clearly owned by the matching language plugin
The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager
In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters
No formatters are moved as part of this change, so practically speaking this is NFC
llvm-svn: 246568
When detaching, we need to detach from all threads of the inferior and not just the main one.
Without this, a multi-threaded inferior would usually crash once the server exits.
llvm-svn: 246549
Linux sometimes sends us a PTRACE_EVENT_EXIT when an inferior process gets a SIGKILL. This can be
confusing, since normally we don't expect any events when the inferior is stopped. This commit
adds code to handle this situation (resume the thread and let it exit normally) and avoid an
assertion failure in ResumeThread().
llvm-svn: 246539
Summary:
find_first_of will look for any of the characters, not the full
string passed in. When looking for "--" then, we must use find
and not find_first_of.
Reviewers: ki.stfu, abidh
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12517
llvm-svn: 246529
Pavel Labath