After switching over LLDB's line table parser to libDebugInfo, we
noticed two regressions on the Windows bot. The problem is that when
obtaining a file from the line table prologue, we append paths without
specifying a path style. This leads to incorrect results on Windows for
debug info containing Posix paths:
0x0000000000201000: /tmp\b.c, is_start_of_statement = TRUE
This patch is an attempt to fix that by guessing the path style whenever
possible.
Differential revision: https://reviews.llvm.org/D66227
llvm-svn: 368879
Although there is nothing wrong with this patch, the test added here
uncovers a problem in other parts of the code which cause the test to
fail when running under asan. Reverting the patch until I can fix the
underlying issue(s).
This reverts commit r368416.
llvm-svn: 368838
Summary:
It seems this was an unintended side-effect of D26698. AFAICT, these
functions did return an empty string before that patch, and the patch
contained code which attempted to ensure that, but those efforts were
negated by ConstString::AsCString, which by default returns a nullptr
even for empty strings.
This patch:
- fixes the GetOutput/Error methods to really return empty strings
- adds and explicit test for that
- removes a workaround in lldbtest.py, which was masking this problem
from our other tests
Reviewers: jingham, clayborg
Subscribers: zturner, lldb-commits
Differential Revision: https://reviews.llvm.org/D65739
llvm-svn: 368806
The isGuardVariableSymbol option for ignoring Microsoft's ABI
was originally added to get the bots green, but now that we found
the actual issue (that we checked for prefix instead of suffix
in the MS ABI check), we should be able to properly implement
the guard variable check without any strange Microsoft exceptions.
llvm-svn: 368802
Summary:
This commit contains three small changes to enable lldb-server on Windows.
- Add lldb-server for Windows to the build
- Disable pty redirection on Windows for the initial lldb-server bring up
- Add a support to get the parent pid for a process on Windows
- Ifdef some signals which aren't supported on Windows
Thanks to Hui Huang for the help with this patch!
Reviewers: labath
Reviewed By: labath
Subscribers: JDevlieghere, compnerd, Hui, amccarth, xiaobai, srhines, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61686
llvm-svn: 368774
My previous change didn't fix the Windows bot. This patch is an attempt
to make guessing the path style more robust by first looking at the
compile dir and falling back to the actual file if that's unsuccessful.
llvm-svn: 368772
Summary: Thanks to Hui Huang and the reviewers for all the help with this patch.
Reviewers: labath, Hui, jfb, clayborg, amccarth
Reviewed By: labath
Subscribers: amccarth, compnerd, dexonsmith, mgorny, jfb, teemperor, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D63165
llvm-svn: 368759
The line number table header was substantially revised in DWARF 5 and is
not fully supported by LLDB's current debug line implementation.
This patch replaces the LLDB debug line parser with its counterpart in
LLVM. This was possible because of the limited contact surface between
the code to parse the DWARF debug line section and the rest of LLDB.
We pay a small cost in terms of performance and memory usage. This is
something we plan to address in the near future.
Differential revision: https://reviews.llvm.org/D62570
llvm-svn: 368742
Summary:
Ideally CompilerType would have no knowledge of clang or any individual
TypeSystem. Decoupling clang is relatively straightforward.
Differential Revision: https://reviews.llvm.org/D66102
llvm-svn: 368741
It seems the broken guard variable check for Windows was a feature(TM)
and not a bug, so let's keep add a flag to the guard check that keeps
the old behavior in the places where we ignored guard variables before.
llvm-svn: 368688
Summary:
And not `zero`. This is the last API needed to be converted to
an Optional<T>.
Reviewers: xiaobai, compnerd
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66093
llvm-svn: 368614
The returned value is currently unused. It also seems to imply that
it somehow represents 'printf-style' the number of characters/bytes
written to some output stream (which is incorrect, as we only know
the actual size of the written message when we have rendered it,
e.g. via GetString and DiagnosticManagers have no associated
output stream).
llvm-svn: 368577
Summary:
Our IR rewriting infrastructure currently fails when it encounters a variable which has no metadata associated.
This causes dynamic_cast to fail as in this case IRForTarget considers the type info pointers ('@_ZTI...') to be
variables without associated metadata. As there are no variables for these internal variables, this is actually
not an error and dynamic_cast would work fine if we didn't throw this error.
This patch fixes this by removing this diagnostics code. In case we would actually hit a variable that has no
metadata (but is supposed to have), we still have the error in the expression log so this shouldn't make it
harder to diagnose any missing metadata errors.
This patch should fix dynamic_cast and also adds a bunch of test coverage to that language feature.
Fixes rdar://10813639
Reviewers: davide, labath
Reviewed By: labath
Subscribers: friss, labath, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65932
llvm-svn: 368511
These types were recently added in D62960 but it seems the patch didn't
consider LLDB which causes a bunch of compiler warnings about
missing enum values. It seems this feature isn't fully implemented yet,
so I don't think we can write any test for this. For now lets just add
the missing types to our usual list of unsupported types.
llvm-svn: 368424
Not NFC as this will probably fix a wrong guard variable check
on Windows. Not sure though what Windows test can now be safely
enabled.
llvm-svn: 368417
Summary:
When opening a minidump, we were failing to find an executable because
we were searching for i386-unknown-windows, whereas we recognize the
pe/coff files as i386-pc-windows. This fixes the triple computation code
in the minidump parser to match pe/coff, and adds an appropriate test.
NB: I'm not sure setting the vendor to "pc" is really correct for
arm(64) windows, but right now that seems to match what we do in the
pe/coff case (ArchSpec.cpp:935).
Reviewers: clayborg, amccarth
Subscribers: javed.absar, kristof.beyls, rnk, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D65955
llvm-svn: 368416
Summary:
This test doesn't make sense. Change to be consistent with what we did
in GDBRemoteCommunication.cpp.
Reviewers: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65965
llvm-svn: 368352
When looking up a type by name, also scan through any referenced Clang
modules regardsless of whether a type with this name has been
found. This is NFCish (= a potential performance regression) for Clang
projects, but necessary in mixed Swift and Objective-C projects (and
tested in swift-lldb).
This only affects projects compiled with -gmodules that were not run
through dsymutil.
llvm-svn: 368345
Value::GetValueAsData() takes an undocumented parameter called
data_offset that is always 0.
Differential Revision: https://reviews.llvm.org/D65910
llvm-svn: 368330
Summary:
This patch removes the GetSymbolVendor function, and the various
mentions of the SymbolVendor in the Module class. The implementation of
GetSymbolVendor is "inlined" into the GetSymbolFile class which I
created earlier.
After this patch, the SymbolVendor class still exists inside the Module
object, but only as an implementation detail -- a fancy holder for the
SymbolFile. That will be removed in the next patch.
Reviewers: clayborg, JDevlieghere, jingham, jdoerfert
Subscribers: jfb, lldb-commits
Differential Revision: https://reviews.llvm.org/D65864
llvm-svn: 368263
This function is unused. It's also wrong, because it computes
the size and the alignment of the type without asking the runtime,
so it doesn't work for any language that has one (e.g. swift).
One could consider re-implementing this passing an execution scope
context, and modifying GetTypeBitAlign() to do the right thing,
but given there are no uses, it's not really useful.
llvm-svn: 368249
If a bitfield doesn't fit into the child_byte_size'd window at
child_byte_offset, move the window forward until it fits. The problem
here is that Value has no notion of bitfields and thus the Value's
DataExtractor is sized like the bitfields CompilerType; a sequence of
bitfields, however, can be larger than their underlying type.
This was not in the big-endian-derived DWARF 2 bitfield attributes
because their offsets were counted from the end of the window, so they
always fit.
rdar://problem/53132189
Differential Revision: https://reviews.llvm.org/D65492
llvm-svn: 368226
When ld64 links a binary deterministically using the flag ZERO_AR_DATE,
it sets a timestamp of 0 for N_OSO members in the symtab section, rather
than the usual last modified date of the object file. Prior to this
patch, lldb would compare the timestamp from the N_OSO member against
the last modified date of the object file, and skip loading the object
file if there was a mismatch. This patch updates the logic to ignore the
timestamp check if the N_OSO member has timestamp 0.
The original logic was added in https://reviews.llvm.org/rL181631 as a
safety check to avoid problems when debugging if the object file was out
of date. This was prior to the introduction of deterministic build in
ld64. lld still doesn't support deterministic build.
Other code in llvm already relies on and uses the assumption that a
timestamp of 0 means deterministic build. For example, commit
9ccfddc39d adds similar timestamp checking
logic to dsymutil, but special cases timestamp 0. Likewise, commit
0d1bb79a04 adds a long comment describing
deterministic archive, which mostly uses timestamp 0 for determinism.
Patch from Erik Chen <erikchen@chromium.org>!
Differential Revision: https://reviews.llvm.org/D65826
llvm-svn: 368199
Resolve the path in the target create output. This is nice when passing
relative paths to the lldb command line driver.
$ lldb ./binary
(lldb) target create "./binary"
Current executable set to '/absolute/path/to/binary' (x86_64).
This change only affects the target create output and does not change
the debugger's behavior. It doesn't resolve symbolic links so it won't
cause confusing when debugging something like clang++ that's symlinked
to clang.
Differential revision: https://reviews.llvm.org/D65611
llvm-svn: 368182
Currently ExecutionContext::GetByteOrder() always returns the host byte
order. This seems like a simple mistake: the return keyword appears to
have been omitted by accident. This patch fixes that and adds a unit
test.
Bugreport: https://llvm.org/PR37950
Differential revision: https://reviews.llvm.org/D48704
llvm-svn: 368181
These are already defined in llvm/BinaryFormat/ELF.h. Leaving the NetBSD
and OpenBSD constants as-is, as they have no llvm counterparts.
llvm-svn: 368168
Summary:
After rL368069 I noticed that HAVE_SYS_TYPES_H is not defined in
Platform.h, or anywhere else in lldb. This change fixes that.
Reviewers: labath
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65822
llvm-svn: 368125
Adrian's changes to support Catalyst processes and my
changes to support debugserver running on an arm64_32
device (Apple Watch Series 4, which uses an IPL32 model
on arm64 cpus).
llvm-svn: 368118
Summary:
In an attempt to make file-address-based lookups more predictable, in D55998
we started ignoring sections which would result in file address
overlaps. It turns out this was too aggressive because thread-local
sections typically will have file addresses which apear to overlap
regular data/code. This does not cause a problem at runtime because
thread-local sections are loaded into memory using special logic, but it
can cause problems for lldb when trying to lookup objects by their file
address.
This patch changes ObjectFileELF to permit thread-local sections to
overlap regular ones by essentially giving them a separate address
space. It also makes them more symmetrical to regular sections by
creating container sections from PT_TLS segments.
Simultaneously, the patch changes the regular file address lookup logic
to ignore sections with the thread-specific bit set. I believe this is
what the users looking up file addresses would typically expect, as
looking up thread-local data generally requires more complex logic (e.g.
DWARF has a special opcode for that).
Reviewers: clayborg, jingham, MaskRay
Subscribers: emaste, aprantl, arichardson, lldb-commits
Differential Revision: https://reviews.llvm.org/D65282
llvm-svn: 368010
After the recent refactorings the SymbolVendor passthrough no longer
serve any purpose. This patch removes those methods, and updates all
callsites to go to the symbol file directly -- in most cases that just
means calling GetSymbolFile()->foo() instead of
GetSymbolVendor()->foo().
llvm-svn: 368001
Summary:
The debug link and build-id lookups are two independent ways one can
search for a separate symbol file. However, our implementation in
SymbolVendorELF was tying the two together and refusing to look up the
symbol file based on a build id if the file did not contain a debug
link.
This patch makes it possible to search for the symbol file with
just one of the two methods available. To demonstrate, I split the
build-id-case test into two, so that we test the search using both
methods.
Reviewers: jankratochvil, mgorny, clayborg, espindola, alexshap
Subscribers: emaste, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65561
llvm-svn: 367994
Summary:
lld r367537 changed the way the linker organizes sections and segments.
This exposed an lldb bug and caused some tests to fail.
In all of the failing tests the root cause was the same -- when we were
trying to resolve the last address in the line_table section, we failed
because it pointed past the end of the section.
This patch changes the line table address resolution code to back up the
address by one for end-of-sequence entries. This ensures the address
still points inside a section/module even if the line table sequence
ends at the very end of a section.
It also reverts the linker flags which were added to the failing tests
to restore previous behavior.
Reviewers: clayborg, jingham
Subscribers: mgorny, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65647
llvm-svn: 367983
Summary:
.. removing IsMeaninglessWithoutTypeResolution(). I'm fairly
confident this was introduced to support swift, where
static types [without dynamic counterpart] don't carry a lot
of value. Since then, the formatters and dynamic type resolution
has been rewritten, and we employ different solutions. This function
is unused here too, so let's get read of it.
<rdar://problem/36377967>
Reviewers: shafik, JDevlieghere, alex, compnerd, teemperor
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65782
llvm-svn: 367957
Summary:
This simplifies the interface, as I'm trying to understand how
we can upstream swift support.
<rdar://problem/36377967>
Reviewers: teemperor, JDevlieghere, xiaobai, compnerd, friss
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65781
llvm-svn: 367946
The UpdateLanguageForExpr should only update the language, but over
time it started to do also do different things related to the generation
of the expression source code. This patch refactors all the source code
generation part into its own function.
llvm-svn: 367922
D65562 <https://reviews.llvm.org/D65562> moves LangStandard.h from clang/Frontend to clang/Basic. This patch
adjusts the single file in lldb that uses it to match.
Tested on x86_64-pc-linux-gnu.
Differential Revision: https://reviews.llvm.org/D65717
llvm-svn: 367865
Currently Target::m_next_persistent_variable_index is counting up
for our persistent variables ($0, $1, ...) but we also have a
unused counter that is supposed to do this in
ClangPersistentVariables but that stays always at 0 (because
we currently increase the target counter when we should increase
that unused counter).
This patch removes the counter in Target and lets the documented
counter in ClangPersistentVariables do the variable counting.
Patch *should* be NFC, but it might unexpectedly bring LLDB to
new code paths that could contain exciting new bugs to fix.
llvm-svn: 367842
The commit changed Module dumping code to call SymbolFile::Dump
directly, which meant that we were no longer showing the plugin name in
the output (as that was done in the SymbolVendor).
This adds the plugin name printing code to the SymbolFile dump method,
and tweak the assertions in the PDB tests to match it correctly.
llvm-svn: 367835
Summary:
The contents of the gnu_debuglink section were passed through the
GetDebugSymbolFilePaths interface, which was more generic than needed.
As the only class implementing this function is ObjectFileELF, we can
modify the function to return just a single FileSpec (instead of a
list). Also, since the SymbolVendorELF already assumes ELF object files,
we don't have to make this method available on the generic ObjectFile
interface -- instead we can put it on ObjectFileELF directly.
This change also makes is so that if the Module has an explicit symbol
file spec set, we disregard the value the value of the debug link
(instead of doing a secondary lookup using that). I think it makes sense
to honor the users wishes if he had explicitly set the symbol file spec,
and this seems to be consistent with what SymbolVendorMacOSX is doing
(SymbolVendorMacOSX.cpp:125).
The main reason for making these changes is to make the treatment of
build-ids and debug links simpler in the follow-up patch.
Reviewers: clayborg, jankratochvil, mgorny, espindola
Subscribers: emaste, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65560
llvm-svn: 367824
Summary:
This patch removes the GetSymtab method from the SymbolVendor, which is
a no-op as it's implementation just forwards to the relevant SymbolFile.
Instead it creates a Module::GetSymtab, which calls the SymbolFile
method directly.
All callers have been updated to use the Module method directly instead
of a two phase GetSymbolVendor->GetSymtab search, which leads to reduced
intentation in a lot of deeply nested code.
Reviewers: clayborg, JDevlieghere, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D65569
llvm-svn: 367820
This function is not portable, and there are only a handful of usages of
it anyway. Replacing it with std::this_thread::sleep_for enables us to
get rid of the compatibility code in PosixApi.h.
llvm-svn: 367814
Summary:
The change https://reviews.llvm.org/D55575 modified ClangASTContext::CreateParameterDeclaration to call decl_ctx->addDecl(decl); this caused a regression since the existing code in DWARFASTParserClang::ParseChildParameters is called with the containing DeclContext. So when end up with cases where we are parsing a parameter for a member function and the parameter is added to the CXXRecordDecl as opposed to the CXXMethodDecl. This example is given in the regression test TestBreakpointInMemberFuncWNonPrimitiveParams.py which without this fix in a modules build leads to assert on setting a breakpoint in a member function with non primitive parameters. This scenario would be common when debugging LLDB or clang.
Differential Revision: https://reviews.llvm.org/D65414
llvm-svn: 367726
Summary: We have been seeing increased reports of performance issue around large project and formatting std::function variables especially in functions signatures in back traces. There are some possible fixes but exploring those fixes may take time and it is better to temporarily disable the formatter due to its impact and re-enable it once we have a fix.
Differential Revision: https://reviews.llvm.org/D65666
llvm-svn: 367701
Summary:
Update StackFrame::GetSymbolContext to mirror the logic in
RegisterContextLLDB::InitializeNonZerothFrame that knows not to do the
pc decrement when the given frame is a signal trap handler frame or the
parent of one, because the pc may not follow a call in these frames.
Accomplish this by adding a behaves_like_zeroth_frame field to
lldb_private::StackFrame, set to true for the zeroth frame, for
signal handler frames, and for parents of signal handler frames.
Also add logic to propagate the signal handler flag from UnwindPlan to
the FrameType on the RegisterContextLLDB it generates, and factor out a
helper to resolve symbol and address range for an Address now that we
need to invoke it in four places.
Reviewers: jasonmolenda, clayborg, jfb
Reviewed By: jasonmolenda
Subscribers: labath, dexonsmith, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64993
llvm-svn: 367691
Summary:
This is the next step in avoiding funneling all SymbolFile calls through
the SymbolVendor. Right now, it is just a convenience function, but it
allows us to update all calls to SymbolVendor functions to access the
SymbolFile directly. Once all call sites have been updated, we can
remove the GetSymbolVendor member function.
This patch just updates the calls to GetSymbolVendor, which were calling
it just so they could fetch the underlying symbol file. Other calls will
be done in follow-ups.
Reviewers: JDevlieghere, clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D65435
llvm-svn: 367664
Reformat OptionEnumValueElement to make it easier to distinguish between
its fields. This also removes the need to disable clang-format for these
arrays.
Differential revision: https://reviews.llvm.org/D65489
llvm-svn: 367638
Summary:
Currently, clang's FileManager uses NULL as an indicator that a particular file
did not exist, but would not propagate errors like permission issues. Instead,
teach FileManager to use llvm::ErrorOr internally and return rich errors for
failures.
Reviewers: arphaman, bruno, martong, shafik
Subscribers: nemanjai, kbarton, MaskRay, jkorous, dexonsmith, kadircet, jsji, cfe-commits, lldb-commits
Tags: #clang, #lldb
Differential Revision: https://reviews.llvm.org/D65534
llvm-svn: 367618
Replaying a reproducer in asynchronous mode never makes sense. This
patch disables asynchronous mode during replay.
Differential revision: https://reviews.llvm.org/D65547
llvm-svn: 367494
Improved the GDB client base documentation while I was reading through
it. Looks like it got messed up during the automatic comment reflow a
while ago.
llvm-svn: 367481
Summary:
The methods to find types in a Target aren't clang specific and are
pretty generalizable to type systems. Additionally, to support some of
the use cases in SBTarget, I've added a "GetScratchTypeSystems" method
to Target to support getting all type systems for a target we are
debugging.
Differential Revision: https://reviews.llvm.org/D64964
llvm-svn: 367480
I was going through some of the old bugs and came across PR21069 which I
was able to reproduce. The issue is that we match the regex `^foo`
against the `DW_AT_name` in the DWARF, which for our anonymous function
is indeed `foo`. However, when we get the function name from the symbol
context, the result is `(anonymous namespace)::foo()`. This throws off
completions, which assumes that it's appending to whatever is already
present on the input, resulting in a bogus
`b fooonymous\ namespace)::foo()`.
Bug report: https://llvm.org/PR21069
Differential revision: https://reviews.llvm.org/D65498
llvm-svn: 367455
Summary:
We've had a bug where two pieces of code, executing on two threads were
attempting to write inferior output simultaneously. The first one was in
Debugger::HandleProcessEvent, which handled the cases where stdout was
coming while the process was running. The second was in
CommandInterpreter::IOHandlerInputComplete, which was ensuring that any
output is printed before the command which caused process to run
terminates.
Both of these things make sense, but the fact they were implemented as
two independent functions without any synchronization meant that race
conditions could occur (e.g. both threads call process->GetSTDOUT, get
two chunks of data, but then end up calling stream->Write in opposite
order). This was most apparent in situations where a process quickly
writes a bunch of output and then exits (as all our register tests do).
This patch adds a mutex to ensure that stdout forwarding happens
atomically. It also refactors a code somewhat in order to reduce code
duplication.
Reviewers: clayborg, jingham
Subscribers: jfb, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D65152
llvm-svn: 367418
Replaced Cmake option based check with the preprocessor macro as CMAKE_SYSTEM_PROCESSOR doesn't work as expected on Windows.
Fixes llvm.org/pr42724
Differential Revision: https://reviews.llvm.org/D65409
llvm-svn: 367414
Summary:
On the heels of D62934, this patch uses the same approach to introduce
llvm RTTI support to the ObjectFile hierarchy. It also replaces the
existing uses of GetPluginName doing run-time type checks with
llvm::dyn_cast and friends.
This formally introduces new dependencies from some other plugins to
ObjectFile plugins. However, I believe this is fine because:
- these dependencies were already kind of there, and the only reason
we could get away with not modeling them explicitly was because the
code was relying on magically knowing what will GetPluginName() return
for a particular kind of object files.
- the dependencies themselves are logical (it makes sense for
SymbolVendorELF to depend on ObjectFileELF), or at least don't
actively get in the way (the JitLoaderGDB->MachO thing).
- they don't introduce any new dependency loops as ObjectFile plugins
don't depend on any other plugins
Reviewers: xiaobai, JDevlieghere, espindola
Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65450
llvm-svn: 367413
Summary:
The last responsibility of the SymbolVendor was to hold an owning
reference to the object file (in case symbols are being read from a
different file than the main module). As SymbolFile classes already hold
a non-owning reference to the object file, we can easily remove this
responsibility of the SymbolVendor by making the SymbolFile reference
owning.
Reviewers: JDevlieghere, clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D65401
llvm-svn: 367392
Bitwise-or with a non-zero constant will always evaluate to true. Switch to
bitwise-and which will only evalute to true if the specified bit is set in the
other operand.
llvm-svn: 367386
Completion requests have two fields that are essentially unimplemented:
`m_match_start_point` and `m_max_return_elements`. This would've been
okay, if it wasn't for the fact that this caused a bunch of useless
parameters to be passed around. Occasionally there would be a comment or
assert saying that they are not supported. This patch removes them.
llvm-svn: 367385
When investigating a completion bug I got confused by the API.
LongestCommonPrefix finds the longest common prefix of the strings in
the string list. Instead of returning that string through an output
argument, just return it by value.
llvm-svn: 367384
Summary:
This commit achieves the following:
- Functions used to return a `TypeSystem *` return an
`llvm::Expected<TypeSystem *>` now. This means that the result of a call
is always checked, forcing clients to move more carefully.
- `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a
non-null pointer to a TypeSystem.
Reviewers: JDevlieghere, davide, compnerd
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D65122
llvm-svn: 367360
As of svn rL367298, SymbolFileDWARF locks the module in many cases where
it needs to parse some aspect of the DWARF symbol file.
SymbolFileDWARF::ParseLineTable needs to lock the module because
SymbolVendor::ParseLineTable no longer locks it.
llvm-svn: 367358
Summary:
Tab completing inside the multiline expression command can cause LLDB to crash. The easiest way
to do this is to go inside a frame with at least one local variable and then try to complete:
(lldb) expr
1. a[tab]
Reason for this was some mixup when we calculate the cursor position. Obviously we should calculate
the offset inside the string by doing 'end - start', but we are doing 'start - end' (which causes the offset to
become -1 which will lead to some out-of-bounds reading).
Fixes rdar://51754005
I don't see any way to test this as the *multiline* expression completion is completely untested at the moment
and I don't think we have any existing code for testing infrastructure for it.
Reviewers: shafik, davide, labath
Reviewed By: labath
Subscribers: abidh, lldb-commits, davide, clayborg, labath
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64995
llvm-svn: 367308
This time, the warning pointed to an actual problem, because the
coff_opt_header structure contained a std::vector. I guess this happened
to work because the all-zero state was a valid representation of an
empty vector, but its not a good idea to rely on that.
I remove the memset, and have the structure clear its members in the
constructor instead.
llvm-svn: 367299
Summary:
The last bit of functionality in SymbolVendor passthrough functions is
the locking the module mutex. While it may be nice doing the locking in
a central place, we weren't really succesful in doing that right now,
because some SymbolFile function could still be called without going
through the SymbolVendor. This meant in SymbolFileDWARF (the only
battle-tested symbol file implementation) roughly a half of the
functions was taking additional locks and another half was asserting
that the lock is already held. By making the SymbolFile responsible for
locking, we can at least make the situation in SymbolFileDWARF more
consistent.
Reviewers: clayborg, JDevlieghere, jingham, jdoerfert
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D65329
llvm-svn: 367298
As discussed in D65249, don't use AlignedCharArray or std::aligned_storage. Just use alignas(X) char Buf[Size];. This will allow me to remove AlignedCharArray entirely, and works on the current minimum version of Visual Studio.
llvm-svn: 367275
Instead of passing the FileCollector around as a reference or raw
pointer, use a shared_ptr. This change's motivation is twofold. First it
adds compatibility for the newly added `FileCollectorFileSystem`.
Secondly, it addresses a lifetime issue we only see when LLDB is used
from Xcode, where a reference to the FileCollector outlives the
reproducer instance.
llvm-svn: 367258
Summary:
This is a bit more explicit, and makes it possible to build LLDB without
varying the -I lines per-directory.
(The latter is useful because many build systems only allow this to be
configured per-library, and LLDB is insufficiently layered to be split into
multiple libraries on stricter build systems).
(My comment on D65185 has some more context)
Reviewers: JDevlieghere, labath, chandlerc, jdoerfert
Reviewed By: labath
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65397
Patch by Sam McCall!
llvm-svn: 367241
Right now our Properties.inc only generates the initializer for the
options list but not the array declaration boilerplate around it. As the
array definition is identical for all arrays, we might as well also let
the Properties.inc generate it alongside the initializers.
Unfortunately we cannot do the same for enums, as there's this magic
ePropertyExperimental, which needs to come at the end to be interpreted
correctly. Hopefully we can get rid of this in the future and do the
same for the property enums.
Differential revision: https://reviews.llvm.org/D65353
llvm-svn: 367238
Summary:
This moves the implementation of the function into the SymbolFile class,
making it possible to excise the SymbolVendor passthrough functions in
follow-up patches.
Reviewers: clayborg, jingham, JDevlieghere
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D65266
llvm-svn: 367231
The Diagnostic class in LLDB is suppossed to be inherited from,
so just copying the diagnostics like this is wrong. The function
is also unused, so lets just get rid of it instead of creating
some cloning facility for it.
llvm-svn: 367201
Summary:
Right now our CommandOptions.inc only generates the initializer for the options list but
not the array declaration boilerplate around it. As the array definition is identical for all arrays,
we might as well also let the CommandOptions.inc generate it alongside the initializers.
This patch will also allow us to generate additional declarations related to that option list in
the future (e.g. a enum class representing the specific options which would make our
handling code less prone).
This patch also fixes a few option tables that didn't follow our naming style.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65331
llvm-svn: 367186
Delete the abstract GetOffset function, which is only defined for
rnglists entries. Instead fix up entries which refer to the range list
classes so that one can statically know that he is dealing with the
rnglists section and call the function that way.
llvm-svn: 367106
We dynamically allocate the option validator which means we
can't mark this list of OptionDefinitions as constexpr. It's also
more complicated than necessary.
llvm-svn: 367102
Summary:
Instead of having SymbolVendor coordinate Symtab construction between
Symbol and Object files, make the SymbolVendor function a passthrough,
and put all of the logic into the SymbolFile.
Reviewers: clayborg, JDevlieghere, jingham, espindola
Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D65208
llvm-svn: 367086
Property definitions are currently defined in a PropertyDefinition array
and have a corresponding enum to index in this array. Unfortunately this
is quite error prone. Indeed, just today we found an incorrect merge
where a discrepancy between the order of the enum values and their
definition caused the test suite to fail spectacularly.
Tablegen can streamline the process of generating the property
definition table while at the same time guaranteeing that the enums stay
in sync. That's exactly what this patch does. It adds a new tablegen
file for the properties, building on top of the infrastructure that
Raphael added recently for the command options. It also introduces two
new tablegen backends: one for the property definitions and one for
their corresponding enums.
It might be worth mentioning that I generated most of the tablegen
definitions from the existing property definitions, by adding a dump
method to the struct. This seems both more efficient and less error
prone that copying everything over by hand. Only Enum properties needed
manual fixup for the EnumValues and DefaultEnumValue fields.
Differential revision: https://reviews.llvm.org/D65185
llvm-svn: 367058
Summary:
This might be an edge case in regular use but if you're shipping an lldb version with no debugserver lldb will try to use the System one.
However, lldb only knows how to find the Xcode one and not the Command Line Tools one. This diff fixes that.
We try to find debugserver with `PlatformDarwin::LocateExecutable("debugserver")`, we call `xcode-select -p` to get the path and then assume this path is of Xcode.
The changes I did are:
* Change `PlatformDarwin::LocateExecutable` to also add the Command Line Tools directory to the list of paths to search for debugserver.
* Created a new function to find the Command Line Tools directory named `GetCommandLineToolsLibraryPath`.
* Refactored the code that calls `xcode-select -p` into its own function `GetXcodeSelectPath()`. There were 2 identical pieces of code for this so I reduced it to one and used this function everywhere instead.
* I also changed `PlatformDarwin::GetSDKDirectoryForModules` to use the `SDKs` directory that exists in the Command Line Tools installation.
I'm not sure how to create tests for this. PlatformDarwinTest is really limited and I couldn't find how to mock Filesystem::Instance() so I could create a virtual file system.
Reviewers: clayborg, JDevlieghere
Reviewed By: clayborg, JDevlieghere
Subscribers: jasonmolenda, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65171
llvm-svn: 367052
Mark the process as stopped when SIGSTOP arrives. This is necessary
for lldb-server to generate correct response to 'process interrupt',
and therefore to prevent the whole stack crashing when process
is stopped.
Thanks to Pavel Labath for the tip.
Differential Revision: https://reviews.llvm.org/D65289
llvm-svn: 367047
Summary:
Here's a replacement for D62504. I thought I could use LoadModules to implement this but in reality I can't because there are at few issues with it:
* The LoadModules assumes that the list returned by GetLoadedModuleList is comprehensive in the sense that reflects all the mapped segments, however, this is not true, for instance VDSO entry is not there since it's loaded manually by LoadVDSO using GetMemoryRegionInfo and it doesn't represent a specific shared object in disk. Because of this LoadModules will unload the VDSO module.
* The loader (interpreter) module might have also been loaded using GetMemoryRegionInfo, this is true when we launch the process and the rendezvous structure is not yet available (done through LoadInterpreterModule()). The problem here is that this entry will point to the same file name as the one found in /proc/pid/maps, however, when we read the same module from the r_debug.link_map structure it might be under a different name. This is true at least on CentOS where the loader is a symlink. Because of this LoadModules will unload and load the module in a way where the rendezvous breakpoint is unresolved but not resolved again (because we add the new module first and remove the old one after).
The symlink issue might be fixable by first unloading the old and loading the news (but sounds super brittle), however, I'm not sure how to fix the VDSO issue.
Since I can't trust it I'm just going to use GetLoadedModuleList directly with the same logic that we use today for when we read the linked list in lldb. The only safe thing to do here is to only calculate differences between different snapshots of the svr4 packet itself. This will also cut the dependency this plugin has from LoadModules.
I separated the 2 logics into 2 different functions (remote and not remote) because I don't like mixing 2 different logics in the same function with if/else's. Two different functions makes it easier to reason with I believe. However, I did abstract away the logic that decides if we should take a snapshot or add/remove modules so both functions could reuse it.
The other difference between the two is that on the UpdateSOEntriesFromRemote I take the snapshot only once when state = Consistent because I didn't find a good reason to always update that, as we already got the list from state = Add | Remove. I probably should use the same logic on UpdateSOEntries though I don't see a reason not to since it's really using the same data, just read in different places. Any thoughts here?
It might also be worthwhile to add a test to make sure we don't unload modules that were not actually "unloaded" like the vdso. I haven't done this yet though.
This diff is also missing the option for svr4 like proposed in https://reviews.llvm.org/D62503#1564296, I'll start working on this but wanted to have this up first.
Reviewers: labath, jankratochvil, clayborg, xiaobai
Reviewed By: labath
Subscribers: srhines, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64013
llvm-svn: 367020
Summary:
Similarly to the compile unit lists, the list of types can also be
managed by the symbol file itself.
Since the only purpose of this list seems to be to maintain an owning
reference to all the types a symbol file has created (items are only
ever added to the list, never retrieved), I remove the passthrough
functions in SymbolVendor and Module. I also tighten the interface of
the function (return a reference instead of a pointer, make it protected
instead of public).
Reviewers: clayborg, JDevlieghere, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D65135
llvm-svn: 366994
Summary:
Due to a logic error, lldb-server ended up asserting/crashing every time
the debugged process attempted an execve(). This fixes the error, and
extends TestExec to work on other platforms too. The "extension"
consists of avoiding non-standard posix_spawn extensions and using the
classic execve() call, which should be available on any platform that
actually supports re-execing. I change the test decorator from
@skipUnlessDarwin to @skipIfWindows.
Reviewers: clayborg, jasonmolenda
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D65207
llvm-svn: 366985
The FileCollector got lifted into LLVM and a shim was introduced in LLDB
to keep the old API that takes FileSpecs. This patch removes that shim
and converts the arguments in place.
llvm-svn: 366975
This patch changes the coding style of the FileCollector from the LLDB
to the LLVM coding style. Alex recently lifted it into LLVM and I
volunteered to do the conversion.
llvm-svn: 366966
The file collector class is useful for creating reproducers,
not just for LLDB, but for other tools as well in LLVM/Clang.
Differential Revision: https://reviews.llvm.org/D65237
llvm-svn: 366956
Summary:
I messed up the logic for this. Fixing with some improvements suggested
by Pavel.
Reviewers: labath, jdoerfert
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D65165
llvm-svn: 366950
This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style format
strings, instead of formatv-style format strings.
So instead of writing:
if (log)
log->Printf("%s\n", str);
You'd write:
LLDB_LOG(log, "%s\n", str);
This change was done mechanically with the command below. I replaced the
spurious if-checks with vim, since I know how to do multi-line
replacements with it.
find . -type f -name '*.cpp' -exec \
sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" +
Differential revision: https://reviews.llvm.org/D65128
llvm-svn: 366936
This fixes the unchecked-error assertion at runtime.
Expected<T> must be checked before access or destruction. Expected<T>
value was in success state. (Note: Expected<T> values in success mode
must still be checked prior to being destroyed).
llvm-svn: 366853
A side effect of this commit was that it exchanged the order of types
and compile units in the output of SymbolVendor::Dump. A couple of PDB
tests dependened on that to assert the links between the two.
While it wouldn't be too hard to update the tests, the change of
ordering was not something I intended to do with that patch, and is easy
to restore the original order, so I do just that.
llvm-svn: 366798
Summary:
SymbolFile classes are responsible for creating CompileUnit instances
and they already need to have a notion of the id<->CompileUnit mapping
(because of APIs like ParseCompileUnitAtIndex). However, the
SymbolVendor has remained as the thing responsible for caching created
units (which the SymbolFiles were calling via convoluted constructs like
"m_obj_file->GetModule()->GetSymbolVendor()->SetCompileUnitAtIndex(...)").
This patch moves the responsibility of caching the units into the
SymbolFile class. It does this by moving the implementation of
SymbolVendor::{GetNumCompileUnits,GetCompileUnitAtIndex} into the
equivalent SymbolFile functions. The SymbolVendor functions become just
a passthrough much like the rest of SymbolVendor.
The original implementations of SymbolFile::GetNumCompileUnits is moved
to "CalculateNumCompileUnits", and are made protected, as the "Get"
function is the external api of the class.
SymbolFile::ParseCompileUnitAtIndex is made protected for the same
reason.
This is the first step in removing the SymbolVendor indirection, as
proposed in
<http://lists.llvm.org/pipermail/lldb-dev/2019-June/015071.html>. After
removing all interesting logic from the SymbolVendor class, I'll proceed
with removing the indirection itself.
Reviewers: clayborg, jingham, JDevlieghere
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D65089
llvm-svn: 366791
This patch removes any remaining instances of LogIfAnyCategoriesSet and
replaces them with the LLDB_LOG macro. This in turn made it possible to
make Log::VAPrintf and Log::VAError private.
llvm-svn: 366768
Summary:
When trying to ascertain what language a variable belongs to, just
checking the compilation unit is often not enough. In r364845 I added a way to
check for a variable's language type, but didn't put it in Variable itself.
Let's go ahead and put it in Variable.
Reviewers: jingham, clayborg
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D64042
llvm-svn: 366733
Patch by Martin Andersson (martin.andersson@evoma.se)
If the process is resumed before the state is changed to "running"
there is a possibility (when single stepping) that the debugger stops
and changes the state to "stopped" before it is first changed to
"running". This causes the process to ignore the stop event (since
the state did not change) which in turn leads the DebuggerThread to
wait indefinitely for the exception predicate in HandleExceptionEvent.
Differential Revision: https://reviews.llvm.org/D62183
llvm-svn: 366703
Just delete the memset as the ELFHeader constructor already
zero-initializes the object. Also clean up the ObjectFileELF
constructors/desctructors while I'm in there.
llvm-svn: 366692
Summary:
We assume in LLDB that every type comes from an ASTContext with an associated ClangASTContext.
However the types inside the ClangModuleDeclVendor don't have a ClangASTContext so we end up
crashing whenever we create a CompilerType for one of these types.
Simplest way to trigger this bug is to just look up NSObject from a module:
(lldb) expr @import Foundation
(lldb) type lookup NSObject
Assertion failed: (m_type_system != nullptr), function CompilerType, file /Users/teemperor/llvm1/llvm-project/lldb/source/Symbol/CompilerType.cpp, line 39.
This patch just creates a ClangASTContext for the ASTContext used by ClangModuleDeclVendor.
Reviewers: davide, shafik
Reviewed By: davide
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64989
llvm-svn: 366653
We intend to make PdbAstBuilder abstract and implement
PdbAstBuilderClang along with any other languages that wish to use
PDBs. Thus, change GetOrCreateDeclForUid from returning a clang decl
to a lldb_private::CompilerDecl.
llvm-svn: 366650
Summary:
Add __kernel_rt_sigreturn to the list of trap handlers for Linux (it's
used as such on aarch64 at least), and __restore_rt as well (used on
x86_64).
Skip decrement-and-recompute for trap handlers in
InitializeNonZerothFrame, as signal dispatch may point the child frame's
return address to the start of the return trampoline.
Parse the 'S' flag for signal handlers from eh_frame augmentation, and
propagate it to the unwind plan.
Reviewers: labath, jankratochvil, compnerd, jfb, jasonmolenda
Reviewed By: jasonmolenda
Subscribers: clayborg, MaskRay, wuzish, nemanjai, kbarton, jrtc27, atanasyan, jsji, javed.absar, kristof.beyls, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D63667
llvm-svn: 366580
Instead of taking a status and potentially returning an invalid address,
return an expected which is guaranteed to contain a valid address.
llvm-svn: 366521
Windows does not have the error EINTR when a blocking syscall is
interrupted by a signal. The ReadFile API that fgets is implemented
with instead use ERROR_OPERATION_ABORTED. Check for that after fgets.
llvm-svn: 366520
The new DriverKit user-land kernel drivers in macOS 10.15 / Catalina
do not have a main() function or an LC_MAIN load command. lldb uses
the address of main() as the return address for inferior function
calls; it puts a breakpoint on main, runs the inferior function call,
and when the main() breakpoint is hit, lldb knows unambiguously that
the inferior function call ran to completion - no other function calls
main.
This change hoists the logic for finding the "entry address" from
ThreadPlanCallFunction to Target. It changes the logic to first
try to get the entry address from the main executable module,
but if that module does not have one, it will iterate through all
modules looking for an entry address.
The patch also adds code to ObjectFileMachO to use dyld's
_dyld_start function as an entry address.
<rdar://problem/52343958>
Differential Revision: https://reviews.llvm.org/D64897
llvm-svn: 366493
Instead of having to write FileSpecList::Append(FileSpec(args)) you can
now call FileSpecList::EmplaceBack(args), similar to
std::vector<>::emplace_back.
llvm-svn: 366489
Summary:
We currently don't support offsetof in the expression evaluator as it is implemented as a macro
(which then calls __builtin_offsetof) in stddef.h. The best solution would be to include that
header (or even better, import Clang's builtin module), but header-parsing and
(cross-platform) importing modules is not ready yet.
Until we get this working with modules I would say we add the macro to our existing macro list
as we already do with other macros from stddef.h/stdint.h. We should be able to drop all of them
once we can import the relevant modules by default.
rdar://26040641
Reviewers: shafik, davide
Reviewed By: davide
Subscribers: clayborg, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64917
llvm-svn: 366476
Beside turning the options into the new tablegen format, this patch
also fixes that a few commands had source file completions for the
"count" and "end-linenumber" arguments (which both accepted only
integers). Reason for that are that somehow we added a '1' instead
of our usual '0' value to the initial value for completion.
llvm-svn: 366425
If a core file has an EFI version string which includes a UUID
(similar to what it returns for the kdp KDP_KERNELVERSION packet)
in the LC_IDENT or LC_NOTE 'kern ver str' load command. In that
case, we should try to find the binary and dSYM for the UUID
listed. The dSYM may have python code which knows how to relocate
the binary to the correct address in lldb's target section load
list and loads other ancillary binaries.
The test case is a little involved,
1. it compiles an inferior hello world apple (a.out),
2. it compiles a program which can create a corefile manually
with a specific binary's UUID encoded in it,
3. it gets the UUID of the a.out binary,
4. it creates a shell script, dsym-for-uuid.sh, which will
return the full path to the a.out + a.out.dSYM when called
with teh correct UUID,
5. it sets the LLDB_APPLE_DSYMFORUUID_EXECUTABLE env var before
creating the lldb target, to point to this dsym-for-uuid.sh,
6. runs the create-corefile binary we compiled in step #2,
7. loads the corefile from step #6 into lldb,
8. verifies that lldb loaded a.out by reading the LC_NOTE
load command from the corefile, calling dsym-for-uuid.sh with
that UUID, got back the path to a.out and loaded it.
whew!
<rdar://problem/47562911>
llvm-svn: 366378
In ClangASTContext::CreateFunctionTemplateSpecializationInfo a TemplateArgumentList is allocated on the stack but is treated as if it is persistent in subsequent calls. When we exit the function func_decl will still point to the stack allocated memory. We will use TemplateArgumentList::CreateCopy instead which will allocate memory out of the DeclContext.
Differential Revision: https://reviews.llvm.org/D64777
llvm-svn: 366365
Summary:
Currently the ClangModulesDeclVendor is spamming the expression log with the compiler flags it is using, which creates a log that looks like this:
```
clang
-fmodules
-fimplicit-module-maps
```
This patch removes all these newlines and just prints the compiler flags in one line as you see in the command line:
```
clang -fmodules -fimplicit-module-maps [...]
```
Reviewers: shafik, davide
Reviewed By: davide
Subscribers: davide, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64858
llvm-svn: 366347
Summary:
A common transformation in NativePDB is to go from lldb types to clang
types and vice versa. This function automates one of those steps.
Differential Revision: https://reviews.llvm.org/D64851
llvm-svn: 366345
Summary:
With LLDB we use localUncachedLookup(), however, that fails to find
Decls when a transparent context is involved and the given DC has
external lexical storage. The solution is to use noload_lookup, which
works well with transparent contexts. But, we cannot use only the
noload_lookup since the slow case of localUncachedLookup is still needed
in some other cases.
These other cases are handled in ASTImporterLookupTable, but we cannot
use that with LLDB since that traverses through the AST which initiates
the load of external decls again via DC::decls().
We must avoid loading external decls during the import becuase
ExternalASTSource is implemented with ASTImporter, so external loads
during import results in uncontrolled and faulty import.
Reviewers: shafik, teemperor, jingham, clayborg, a_sidorin, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits, lldb-commits
Tags: #clang, #lldb
Differential Revision: https://reviews.llvm.org/D61333
llvm-svn: 366325
Summary:
We intend to make PdbAstBuilder abstract and implement
PdbAstBuilderClang along with any other languages that wish to use
PDBs. This is the first step.
Differential Revision: https://reviews.llvm.org/D64852
llvm-svn: 366293
Summary:
ReadFile on Windows is supposed to set ERROR_OPERATION_ABORTED according
to the docs on MSDN. However, this has evidently been a known bug since
Windows 8. Therefore, we can't detect if a signal interrupted in the
fgets. So pressing ctrl-c causes the repl to end and the process to
exit. A temporary workaround is just to attempt to fgets twice until
this bug is fixed.
A possible alternative would be to set a flag in the `sigint_handler`
and simply check that flag in the true part of the if statement.
However, signal handlers on Windows are asynchronous and this would
require sleeping on the repl loop thread while still not necessarily
guarnateeing that you caught the sigint.
Reviewers: jfb
Differential Revision: https://reviews.llvm.org/D64660
llvm-svn: 366281
It seems having two Options.inc files in the same project is giving our
custom Xcode project a hard time. This patch renames the new Options.inc
to CommandOptions.inc to prevent this conflict.
llvm-svn: 366196
Summary:
Following up to my CPPLanguageRuntime change, I'm moving
ObjCLanguageRuntime into a plugin as well.
Reviewers: JDevlieghere, compnerd, jingham, clayborg
Subscribers: mgorny, arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D64763
llvm-svn: 366148
Summary: This patch adds documentation that should make it easier to migrate from using the old initializers to the table gen format.
Reviewers: jingham
Reviewed By: jingham
Subscribers: abidh, lldb-commits, JDevlieghere
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64670
llvm-svn: 366083
Summary: This seems better suited to be in a plugin.
Reviewers: JDevlieghere, clayborg, jingham, compnerd, labath
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D64599
llvm-svn: 365951
Summary:
Instead of hardcoding ClangASTContext and ObjCLanguageRuntime, we can
generalize this by creating the method GetRuntimeType in
LanguageRuntime and moving the current MaybeCalculateCompleteType
implementation into ObjCLanguageruntime::GetRuntimeType
Reviewers: jingham, clayborg, JDevlieghere
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D64159
llvm-svn: 365939
Summary:
We currently have man large arrays containing initializers for our command options.
These tables are tricky maintain as we don't have any good place to check them for consistency and
it's also hard to read (`nullptr, {}, 0` is not very descriptive).
This patch fixes this by letting table gen generate those tables. This way we can have a more readable
syntax for this (especially for all the default arguments) and we can let TableCheck check them
for consistency (e.g. an option with an optional argument can't have `eArgTypeNone`, naming of flags', etc.).
Also refactoring the related data structures can now be done without changing the hundred of option initializers.
For example, this line:
```
{LLDB_OPT_SET_ALL, false, "hide-aliases", 'a', OptionParser::eNoArgument, nullptr, {}, 0, eArgTypeNone, "Hide aliases in the command list."},
```
becomes this:
```
def hide_aliases : Option<"hide-aliases", "a">, Desc<"Hide aliases in the command list.">;
```
For now I just moved a few initializers to the new format to demonstrate the change. I'll slowly migrate the other
option initializers tables in separate patches.
Reviewers: JDevlieghere, davide, sgraenitz
Reviewed By: JDevlieghere
Subscribers: jingham, xiaobai, labath, mgorny, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64365
llvm-svn: 365908
Summary:
IRDynamicChecks in its current form is specific to Clang since it deals
with the C language family. It is possible that we may want to
instrument code generated for other languages, but we can factor in a
more general mechanism to do so at a later time.
This decouples ObCLanguageRuntime from Expression!
Reviewers: compnerd, clayborg, jingham, JDevlieghere
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D64591
llvm-svn: 365853
Jordan Rupprecht