this was needed because lldb-mi temporarily contained references to private lldb symbols
(lldb_private namespace), which it shouldn't have. The situation has since been rectified and
this wasn't the right fix anyway, since it can lead to funny ODR violations.
llvm-svn: 264733
FileSystem::Fopen is a lldb_private API, but lldb-mi uses only the
public API. Depending on lldb_private APIs makes Xcode builds fail.
I reverted the portion of r264074 that added such a dependency.
llvm-svn: 264113
Win32 API calls that are Unicode aware require wide character
strings, but LLDB uses UTF8 everywhere. This patch does conversions
wherever necessary when passing strings into and out of Win32 API
calls.
Patch by Cameron
Differential Revision: http://reviews.llvm.org/D17107
Reviewed By: zturner, amccarth
llvm-svn: 264074
We want to do a better job presenting errors that occur when evaluating
expressions. Key to this effort is getting away from a model where all
errors are spat out onto a stream where the client has to take or leave
all of them.
To this end, this patch adds a new class, DiagnosticManager, which
contains errors produced by the compiler or by LLDB as an expression
is created. The DiagnosticManager can dump itself to a log as well as
to a string. Clients will (in the future) be able to filter out the
errors they're interested in by ID or present subsets of these errors
to the user.
This patch is not intended to change the *users* of errors - only to
thread DiagnosticManagers to all the places where streams are used. I
also attempt to standardize our use of errors a bit, removing trailing
newlines and making clients omit 'error:', 'warning:' etc. and instead
pass the Severity flag.
The patch is testsuite-neutral, with modifications to one part of the
MI tests because it relied on "error: error:" being erroneously
printed. This patch fixes the MI variable handling and the testcase.
<rdar://problem/22864976>
llvm-svn: 263859
The Windows SDK provides a version of signal() that is much more
limited compared to other platforms. It only supports about 5-6
signal values. LLDB uses signals for a number of things, most
notably to handle Ctrl+C so we can gracefully shut down. The
portability solution to this on Windows has been to provide a
hand-rolled implementation of `signal` using the name `signal`
so that you could write code that simply calls signal directly
and it would work.
But this introduces a multiply defined symbol with the builtin
version and depending on how you included header files, you could
get yourself into a situation where you had linker errors. To
make matters worse, it led to a ton of compiler warnings. Worst
of all though is that this custom implementation of signal was,
in fact, identical for the purposes of handling Ctrl+C as the
builtin implementation of signal. So it seems to have literally
not been serving any useful purpose.
This patch deletes all the custom signal() functions for Windows,
and includes the signal.h system header, so that any calls to
signal now go to the actual version provided by the Windows SDK.
Differential Revision: http://reviews.llvm.org/D18287
llvm-svn: 263858
Summary:
Signalfd is not used in the code anymore, and given that the same functionality can be achieved
with the new MainLoop class, it's unlikely we will need it in the future. Remove all traces of
it.
Reviewers: tberghammer, ovyalov
Subscribers: tberghammer, danalbert, srhines, lldb-commits
Differential Revision: http://reviews.llvm.org/D17510
llvm-svn: 261631
working directory by default -- a typical security problem that we
need to be more conservative about.
It adds a new target setting, target.load-cwd-lldbinit which may
be true (always read $cwd/.lldbinit), false (never read $cwd/.lldbinit)
or warn (warn if there is a $cwd/.lldbinit and don't read it). The
default is set to warn. If this is met with unhappiness, we can look
at changing the default to true (to match current behavior) on a
different platform.
This does not affect reading of ~/.lldbinit - that will still be read,
as before. If you run lldb in your home directory, it will not warn
about the presence of a .lldbinit file there.
I had to add two SB API - SBHostOS::GetUserHomeDirectory and
SBFileSpec::AppendPathComponent - for the lldb driver code to be
able to get the home directory path in an OS neutral manner.
The warning text is
There is a .lldbinit file in the current directory which is not being read.
To silence this warning without sourcing in the local .lldbinit,
add the following to the lldbinit file in your home directory:
settings set target.load-cwd-lldbinit false
To allow lldb to source .lldbinit files in the current working directory,
set the value of this variable to true. Only do so if you understand and
accept the security risk.
<rdar://problem/24199163>
llvm-svn: 261280
Summary:
The BUILD_SHARED_LIBS branch of lldb-server link flags was hopelessly broken, at least since we
started restricting the symbols exported by liblldb. lldb-server depends on symbols from the
lldb_private namespace, so it cannot link to the public interface of liblldb. Instead I make it
link to the individual libraries constituting liblldb, just like it does in the
!BUILD_SHARED_LIBS case.
This does not make the BUILD_SHARED_LIBS build of lldb fully functional yet, due to the way
liblldb dependencies are managed, but it's a step in that direction.
Reviewers: zturner, tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16678
llvm-svn: 259188
We had some #ifdefs that were looking for the wrong #defines and as a result
debugserver didn't have support for certain simulators. This patch resolves
the problem.
llvm-svn: 258365
at each public stop to improve performance a bit. Most of the
information lldb needed was already in the jThreadsInfo response;
complete that information and catch a few cases where we could still
fall back to getting the information via discrete memory reads.
debugserver adds 'associated_with_dispatch_queue' and 'dispatch_queue_t
keys to the jThreadsInfo response for all the threads. lldb needs the
dispatch_queue_t value. And associated_with_dispatch_queue helps to
identify which threads definitively don't have any queue information so
lldb doesn't try to do memory reads to get that information just because
it was absent in the jThreadsInfo response.
Remove the queue information from the questionmark (T) packet. We'll
get the information for all threads via the jThreadsInfo response -
sending the information for the stopping thread (on all the private
stops, plus the less frequent public stop) was unnecessary information
being sent over the wire.
SystemRuntimeMacOSX will try to get information about queues by asking
the Threads for them, instead of reading memory.
ProcessGDBRemote changes to recognize the new keys being sent in the
jThreadsInfo response. Changes to ThreadGDBRemote to track the new
information. Also, when a thread is marked as definitively not
associated with a libdispatch queue, don't fall back to the system
runtime to try memory reads to find the queue name / kind / ID etc.
<rdar://problem/23309359>
llvm-svn: 257453
keys before we print the libdispatch queues keys (qname, qkind, qserialnum)
to make it easier to read the packet by hand. No function difference, just
reordering the keys in the output.
llvm-svn: 257229
"qserial" to "qserialnum" because "qserial" looks a lot like the
queue type (either 'serial' or 'concurrent') and can be confusing
to read through. debugserver passes these up either in the questionmark
("T") packet, or in the response to the jThreadsInfo packet.
llvm-svn: 257121
This patch adds support the command 'source info' as follows:
(lldb) help source info
Display source line information (as specified) based on the current executable's
debug info.
Syntax: source info <cmd-options>
Command Options Usage:
source info [-c <count>] [-s <shlib-name>] [-f <filename>] [-l <linenum>] [-e <linenum>]
source info [-c <count>] [-s <shlib-name>] [-n <symbol>]
source info [-c <count>] [-a <address-expression>]
-a <address-expression> ( --address <address-expression> )
Lookup the address and display the source information for the corresponding
file and line.
-c <count> ( --count <count> )
The number of line entries to display.
-e <linenum> ( --end-line <linenum> )
The line number at which to stop displaying lines.
-f <filename> ( --file <filename> )
The file from which to display source.
-l <linenum> ( --line <linenum> )
The line number at which to start the displaying lines.
-n <symbol> ( --name <symbol> )
The name of a function whose source to display.
-s <shlib-name> ( --shlib <shlib-name> )
Look up the source in the given module or shared library (can be specified
more than once).
For example:
(lldb) source info --file x.h
Lines for file x.h in compilation unit x.cpp in `x
[0x0000000100000d00-0x0000000100000d10): /Users/dawn/tmp/./x.h:10
[0x0000000100000d10-0x0000000100000d1b): /Users/dawn/tmp/./x.h:10
The new options are used to fix the MI command:
-symbol-list-lines <file>
which didn't work for header files because it called:
target modules dump line-table <file>
which only dumps line tables for a compilation unit.
The patch also fixes a bug in the error reporting when no files were supplied to the command. Previously you'd get:
(lldb) target modules dump line-table
error:
Syntax:
error: no source filenames matched any command arguments
Now you get:
error: file option must be specified.
Reviewed by: clayborg, jingham, ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15593
llvm-svn: 256863
debugserver. thread-pcs has a comma separated list of base 16
addresses - the current pc value for every thread in the process.
It is a partner of the "threads:" key where a list of thread IDs
is given. The pc values in thread-pcs correspond one-to-one with
the thread IDs in the threads list.
This is a part of performance work. When lldb is instruction
stepping / fast stepping over a range of addresses for e.g. a "next"
command, and it steps in to another function, lldb will put a
breakpoint on the return address and continue the process. Before
it calls continue, it calls Thread::SetupForResume on all the
threads, and SetupForResume needs to get the current pc value for
every thread to see if any are at a breakpoint site.
The result is that issuing a "c" continue requires that we send
"read pc register" packets for every thread.
We may do this sequence of step-into-function / continue-to-get-out
many times for a single user-visible "next" or "step" command, and
with highly multithreaded programs, we are sending many extra
packets to get all the thread values.
I looked at including this data in the "jstopinfo" JSON that
we already have in the T packet. But there are three problems that
would make this increase the size of the T packet significantly.
First, numbers in JSON are base 10. Second, a proper JSON would
have something like "thread_pcs": { "34224331112":383772734222, ...}
for thread-id 34224331112 and pc 383772734222 - so we're including
a whole extra copy of the thread id in addition to the pc. Third,
the JSON text is hex-ascii'fied so the size of it is doubled.
In one example,
threads:585db8,585dc7,585dc8,585dc9,585dca,585dce;thread-pcs:100001400,7fff8badc6de,7fff8badcff6,7fff8badc6de,7fff8badc6de,7fff8badc6de;
The "thread-pcs" adds 86 characters - 136 characters for both
threads and thread-pcs. Doing this in JSON would look like
threads={"5791160":4294972416,"5791175":140735536809694,"5791176":140735536812022,"5791177":140735536809694,"5791178":140735536809694,"5791182":140735536809694}
or 160 characters -- or 320 characters once it is hex-asciified.
Given that it's 86 characters vrs 320, I went with the old style
approach. I've seen real world programs that have up to 60 threads
in them, so this could result in vastly larger packets if it
was all done in the JSON with hex-ascii expansion.
If we had an all-JSON T packet, where we didn't need to hex-ascii
encode anything, that would have been the better approach. But
we'd already have a list of threads in JSON at that point so
the additional text wouldn't be too bad.
I'm working on finishing the patches to lldb to use this data;
will commit those once I've had a chance to test them more. But
I wanted to commit the debugserver bits which are more
straightforward.
<rdar://problem/21963031>
llvm-svn: 255711
include two stack frames worth of unwind information instead of
just one -- the unwinder is trying to fetch two stack frames in
more instances now and we're sending extra memory reads resulting
in a performance degredation while stepping.
llvm-svn: 255417
The standard remote debugging workflow with gdb is to start the
application on the remote host under gdbserver (e.g.: gdbserver :5039
a.out) and then connect to it with gdb.
The same workflow is supported by debugserver/lldb-gdbserver with a very
similar syntax but to access all features of lldb we need to be
connected also to an lldb-platform instance running on the target.
Before this change this had to be done manually with starting a separate
lldb-platform on the target machine and then connecting to it with lldb
before connecting to the process.
This change modifies the behavior of "platform connect" with
automatically connecting to the process instance if it was started by
the remote platform. With this command replacing gdbserver in a gdb
based worflow is usually as simple as replacing the command to execute
gdbserver with executing lldb-platform.
Differential revision: http://reviews.llvm.org/D14952
llvm-svn: 255016
Allow both '-var-list-children var0' and '-var-list-children "var0"' to be used with the -var-list-children command. GDB MI allows for this and it is necessary if the variable name contains spaces, such as var5.std::_Vector_base<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<cahr> > > >.
Differential Revision: http://reviews.llvm.org/D15168
llvm-svn: 254941
Summary: This diff approaches building the project natively on NetBSD with the autoconf/gmake framework.
Patch by Kamil Rytarowski. Thanks!
Reviewers: emaste, clayborg
Subscribers: tberghammer, joerg, brucem, lldb-commits
Differential Revision: http://reviews.llvm.org/D14531
llvm-svn: 253153
Summary:
These changes are still incomplete, but we are almost there.
Changes:
- CMake and gmake code
- SWIG code
- minor code additions
Reviewers: emaste, joerg
Subscribers: youri, akat1, brucem, lldb-commits, joerg
Differential Revision: http://reviews.llvm.org/D14042
llvm-svn: 252403
is running under System Integrity Protection on
Mac OS X 10.11. The rootless_allows_task_for_pid() spi
(see debugserver RNBRemote.cpp) is the final SPI that
is used for this - should add support for that too at
some point.
llvm-svn: 252228
Let the editor also clean up whitespace for that file.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13816
llvm-svn: 251979
Summary:
As per the following link, the "--" separator can appear between the options
and parameters of any MI command. Previously this separator was only
handled by the `-data-disassemble` MI command. I have moved the relevant
code into `CMICmdBase` so that any MI command can handle the
aforementioned separator.
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Input-Syntax.html#GDB_002fMI-Input-Syntax
Reviewers: ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14197
llvm-svn: 251793
Summary:
I observed that eclipse was passing --thread-group for many other commands
then we are currently handling. Looking at the MI documentation, the
following link states that each MI command accept the --thread and
--frame option. Looking at the GDB implementation, it seems that apart
from these 2, --thread-group is also handled the same way.
https://sourceware.org/gdb/onlinedocs/gdb/Context-management.html#Context-management
So instead of handling those arguments in every comamnds, I have moved
them into the base class and removed them from elsewhere. Now any command
can use these arguments. The patch seems big but most of the changes are
mechanical.
Reviewers: ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14177
llvm-svn: 251636
A variable of type:
struct S {
union {
int i1;
unsigned u1;
};
union {
int i2;
unsigned u2;
};
};
had been impossible to evaluate in lldb-mi, because MI assigns '??' as the
variable name to each of the unnamed unions after "-var-list-children" command.
Also '??' incorrectly goes to 'exp' field which is treated by IDE as a
structure field name and is displayed in watch window.
The patch fixes this returning empty string as type name for unnamed union and
assigning $N to variable name, where N is the field number in the parent entity.
Patch from evgeny.leviant@gmail.com
Reviewed by: clayborg, abidh
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13947
llvm-svn: 251176
This fixes the OSX build for XCode versions older than 7 by skipping
references to LC_VERSION_MIN_TVOS and LC_VERSION_MIN_WATCHOS if
TARGET_OS_TV or TARGET_OS_WATCH aren't defined.
Reviewed by: jasonmolenda
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14036
llvm-svn: 251172
Summary:
These changes aren't everything what is needed for the CMake target, but it's significantly approaching it.
These changes shouldn't effect the build process on other platforms.
Patch by Kamil Rytarowski, thanks!
Reviewers: joerg, brucem
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13711
llvm-svn: 251164
previous release. Most of the diffs are duplication in the xcode
project file caused by adding a "debugserver-mini" target. Jim
Ingham added support for a new SPI needed to request app launches
on iOS. Greg Clayton added code to indicate the platform of the
binary (macosx, ios, watchos, tvos) based on Mach-O load commands.
Jason Molenda added code so debugserver will identify when it is
running on a tvos/watchos device to lldb.
llvm-svn: 251091
Previously, lldb did not use type summaries for simple types with no children
(like function pointers). This patch enables MI to use lldb type summaries for
evaluation of all types of objects, so MI own formatters are no longer needed.
Patch from evgeny.leviant@gmail.com
Reviewed by: abidh
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13799
llvm-svn: 251082
This makes LLDB launch and create a REPL, specifying no target so that the REPL
can create one for itself. Also added the "--repl-language" option, which
specifies the language to use. Plumbed the relevant arguments and errors
through the REPL creation mechanism.
llvm-svn: 250773
In r248047, I attempted to fix a build breakage introduced by using
llvm's regex support from lldb-mi. However, my approach was flawed
when LLVM and lldb are dynamically linked, in which case two copies
of LLVMSupport would end up in memory, causing crashes on lldb start up.
Instead, use LINK_COMPONENTS to make sure lldb-mi has access to the
LLVMSupport symbols without causing duplication in the dynamic library
case.
llvm-svn: 250751
Summary:
Add dependencies to the custom commands so that they get
re-executed as needed.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13580
llvm-svn: 249860
Summary:
This is Darwin only.
The symbol defined by ${LLDB_VERS_GENERATED_FILE} is used by
source/lldb.cpp, so anything that uses lldb.cpp (which is in
lldbBase) should also have the generated symbol. This means
that the entire process can be centralized within source/CMakeLists.txt
where lldbBase is constructed.
Additionally, the custom command should have dependencies on the
project file as well as the generation script so that if either
changes, the version file is correctly re-generated and everything
is re-linked appropriately.
* cmake/LLDBDependencies.cmake: Remove everything related to
the generated version file from here.
* source/CMakeLists.txt: On Darwin, add the generated version
file to the sources that make up lldbBase. Also, create a
custom target and make lldbBase depend on it to re-generate
the generated file as needed.
* source/API/CMakeLists.txt: Don't need to build the generated
version file here or use it to control linking against swig_wrapper.
* tools/lldb-server/CMakeLists.txt: Likewise.
Reviewers: dawn, sas, clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13552
llvm-svn: 249806
If a string contained characters outside the ASCII range, lldb-mi would
print them as hexadecimal codes. This patch fixes this behaviour by
converting to UTF-8 instead, by having lldb-mi use registered type
summary providers, when they are available. This patch also fixes
incorrect evaluation of some composite types, like std::string, by
having them use a type registered type summary provider.
Based on patch from evgeny.leviant@gmail.com
Reviewed by: ki.stfu, granata.enrico, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13058
llvm-svn: 249597
This patch adds a --start option to the lldb-mi -exec-run command for
getting process stopped at entry point after launch. It is equivelent
to the -s option in the lldb command line interpreter:
process launch -s
and is therefore not supported on all hosts and/or targets. To check
if the --start option is supported, see if the corresponding feature
"exec-run-start-option" is in the list of options reported by the lldb-mi
"-list-features" command.
Patch from engineer.developer@gmail.com (Kirill Lapshin)
Reviewed by: ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12977
llvm-svn: 249072
Fix assignment operator in CMIUtilString to not crash the debugger if it
is passed a NULL pointer, which can happen in code like the following:
SBValue val;
CMIUtilString s;
//...
s = val.GetSummary();
Patch from evgeny.leviant@gmail.com
Reviewed by: clayborg, ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13094
llvm-svn: 248597
Summary:
Following on from r247991:
pthread is in LLDB_SYSTEM_LIBS so there's no need to explicitly add it to the link.
Reviewers: labath
Subscribers: lldb-commits, labath, krytarowski
Differential Revision: http://reviews.llvm.org/D12964
llvm-svn: 248177
Summary:
This switches the decision as to whether or not to lldb-server should
be built to check the same flag that was added that controls whether
or not it is added as a dependency to the 'lldb' target.
It also sets that flag on FreeBSD to maintain parity with the existing
build configuration / situation on FreeBSD.
Reviewers: labath, emaste, tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12925
llvm-svn: 247913
This fixes -data-info-line and -symbol-list-lines to parse the filename
and line correctly when line entries don't have the optional column
number and the filename contains a Windows drive letter. It also fixes
-symbol-list-lines when code from header files is generated.
Reviewed by: abidh, ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12115
llvm-svn: 247899
ninja lldb now does the following:
* forces the python post-build step to fire, which sets up the python lldb module properly.
* on Darwin and Linux, requires the lldb-server target to be built.
* on Darwin, requires the debugserver target to be built.
See http://reviews.llvm.org/D12899 for details.
llvm-svn: 247810
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
"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
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:
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 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: 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
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
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
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:
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
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:
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
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