The Swift stdlib uses absolute symbols in the dylib to communicate
feature flags to the process. LLDB's expression evaluator needs to be
able to find them. This wires up absolute symbols so they show up in
the symtab lookup command, which is also all that's needed for them to
be visible to the expression evaluator JIT.
rdar://85093828
Differential Revision: https://reviews.llvm.org/D113445
LIT skips various system environment variables while building test
config. It turns out that we require PLATFORM environment variable for
detection of x86 vs Arm windows platform.
This patch adds system environment variable PLATFORM into LIT test
config for detection of win32 Arm platform.
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D113165
In 7f01f78593d6 [lldb] update TestEchoCommands -- I fixed this test,
but not on windows, becuase I used some unix shell syntax that
doesn't work with cmd.exe. Fixed it so it will work in both.
Test logic is the same.
This is a trivial fix, so bypassing review to get the build clean again
ASAP.
Followup to https://reviews.llvm.org/D112988
Sorry, I broke this test. The test was verifying the bad behavior
of --source-quietly that the previous change fixed -- namely that
it still echos the initial list of startup commands while
sourcing them.
Updated the test to verify that --source-quietly is quiet, rather than
loud.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D113047
Jim says:
lldb has a -Q or --source-quietly option, which supposedly does:
--source-quietly Tells the debugger to execute this one-line lldb command before any file has been loaded.
That seems like a weird description, since we don't generally use source for one line entries, but anyway, let's try it:
> $LLDB_LLVM/clean-mono/build/Debug/bin/lldb -Q "script print('I should be quiet')" a.out -O "script print('I should be before')" -o "script print('I should be after')"
(lldb) script print('I should be before')
I should be before
(lldb) target create "script print('I should be quiet')"
error: unable to find executable for 'script print('I should be quiet')'
That was weird. The first real -O gets sourced but not quietly, then the argument to the -Q gets treated as the target.
> $LLDB_LLVM/clean-mono/build/Debug/bin/lldb -Q a.out -O "script print('I should be before')" -o "script print('I should be after')"
(lldb) script print('I should be before')
I should be before
(lldb) target create "a.out"
Current executable set to '/tmp/a.out' (x86_64).
(lldb) script print('I should be after')
I should be after
Well, that's a little better, but the -Q option seems to have done nothing.
---
This fixes the description of --source-quietly, as well as causing it
to actually suppress echoing while executing the initialization
commands.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D112988
LLDB build were failing due to following two test failures:
lldb-shell :: ObjectFile/ELF/basic-info.yaml
lldb-shell :: SymbolFile/DWARF/x86/debug-types-address-ranges.s
There were caused by commit 6506907a0a1a8a789ad7036ef911f7e31213c9a5
Front-load the first_valid_code_address check, so that we avoid creating
the function object (instead of simply refusing to use it in queries).
Differential Revision: https://reviews.llvm.org/D112310
Based on post-commit review discussion on
2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith.
Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).
This was originally committed in 277623f4d5a672d707390e2c3eaf30a9eb4b075c
Reverted in f9ad1d1c775a8e264bebc15d75e0c6e5c20eefc7 due to breakages
outside of clang - lldb seems to have some strange/strong dependence on
"char [N]" versus "char[N]" when printing strings (not due to that name
appearing in DWARF, but probably due to using clang to stringify type
names) that'll need to be addressed, plus a few other odds and ends in
other subprojects (clang-tools-extra, compiler-rt, etc).
This patch fixes a problem introduced by clang change
https://reviews.llvm.org/D95617 and described by
https://bugs.llvm.org/show_bug.cgi?id=50076#c6, where inlined functions
omit unused parameters both in the stack trace and in `frame var`
command. With this patch, the parameters are listed correctly in the
stack trace and in `frame var` command.
Specifically, we parse formal parameters from the abstract version of
inlined functions and use those formal parameters if they are missing
from the concrete version.
Differential Revision: https://reviews.llvm.org/D110571
specifically, ignore addresses that point before the first code section.
This resurrects D87172 with several notable changes:
- it fixes a bug where the early exits in InitializeObject left
m_first_code_address "initialized" to LLDB_INVALID_ADDRESS (0xfff..f),
which caused _everything_ to be ignored.
- it extends the line table fix to function parsing as well, where it
replaces a similar check which was checking the executable permissions
of the section. This was insufficient because some
position-independent elf executables can have an executable segment
mapped at file address zero. (What makes this fix different is that it
checks for the executable-ness of the sections contained within that
segment, and those will not be at address zero.)
- It uses a different test case, with an elf file with near-zero
addresses, and checks for both line table and function parsing.
Differential Revision: https://reviews.llvm.org/D112058
There is no reason why this function should be returning a ConstString.
While modifying these files, I also fixed several instances where
GetPluginName and GetPluginNameStatic were returning different strings.
I am not changing the return type of GetPluginNameStatic in this patch, as that
would necessitate additional changes, and this patch is big enough as it is.
Differential Revision: https://reviews.llvm.org/D111877
When we know the bounds of the array, print any embedded nuls instead of
treating them as terminators. An exception to this rule is made for the
nul character at the very end of the string. We don't print that, as
otherwise 99% of the strings would end in \0. This way the strings
usually come out the same as how the user typed it into the compiler
(char foo[] = "with\0nuls"). It also matches how they come out in gdb.
This resolves a FIXME left from D111399, and leaves another FIXME for dealing
with nul characters in "escape-non-printables=false" mode. In this mode the
characters cause the entire summary string to be terminated prematurely.
Differential Revision: https://reviews.llvm.org/D111634
JSON crashlogs have an optional field named reportNotes that contains
any potential errors encountered by the crash reporter when generating
the crashlog. Parse and display them in LLDB.
Differential revision: https://reviews.llvm.org/D111339
Gracefully deal with JSON crashlogs that don't have thread state
available and print an error saying as much: "No thread state (register
information) available".
rdar://83955858
Differential revision: https://reviews.llvm.org/D111341
This reverts c7f16ab3e3f27d944db72908c9c1b1b7366f5515 / r109694 - which
suggested this was done to improve consistency with the gdb test suite.
Possible that at the time GCC did not canonicalize integer types, and so
matching types was important for cross-compiler validity, or that it was
only a case of over-constrained test cases that printed out/tested the
exact names of integer types.
In any case neither issue seems to exist today based on my limited
testing - both gdb and lldb canonicalize integer types (in a way that
happens to match Clang's preferred naming, incidentally) and so never
print the original text name produced in the DWARF by GCC or Clang.
This canonicalization appears to be in `integer_types_same_name_p` for
GDB and in `TypeSystemClang::GetBasicTypeEnumeration` for lldb.
(I tested this with one translation unit defining 3 variables - `long`,
`long (*)()`, and `int (*)()`, and another translation unit that had
main, and a function that took `long (*)()` as a parameter - then
compiled them with mismatched compilers (either GCC+Clang, or
Clang+(Clang with this patch applied)) and no matter the combination,
despite the debug info for one CU naming the type "long int" and the
other naming it "long", both debuggers printed out the name as "long"
and were able to correctly perform overload resolution and pass the
`long int (*)()` variable to the `long (*)()` function parameter)
Did find one hiccup, identified by the lldb test suite - that CodeView
was relying on these names to map them to builtin types in that format.
So added some handling for that in LLVM. (these could be split out into
separate patches, but seems small enough to not warrant it - will do
that if there ends up needing any reverti/revisiting)
Differential Revision: https://reviews.llvm.org/D110455
JSON crashlogs normally start with a single line of meta data that we
strip unconditionally. Some producers started omitting the meta data
which tripped up crashlog. Be more resilient by only removing the first
line when we know it really is meta data.
rdar://82641662
At first, lli only supported lazy mode for ORC. Greedy mode was added with e1579894d205 and is the default settings now. JITLoaderGDB tests don't rely on laziness, so we can switch them to greedy and remove some complexity.
lit.util.which('link') picks up the wrong link.exe in git bash, leading
to this error:
# command stderr:
/usr/bin/link: extra operand '/LIBPATH:C:\\Progra....'
Try '/usr/bin/link --help' for more information.
Instead, assume that link.exe is next to cl.exe.
Differential Revision: https://reviews.llvm.org/D109832
Remove the parent output checks, as they make the test flaky while
serving no real purpose. If the parent crashed/hanged, it will never
resume the child and the test would fail anyway.
We set breakpoint on child_func, so synchronization inside it is too
late to guarantee ordering between the parent output and child
breakpoint. Split the function in two, and perform synchronization
before the breakpoint.
Differential Revision: https://reviews.llvm.org/D109591
Add synchronization routines to ensure that Subprocess tests output
in a predictable order, and all test strings are output before the tests
terminate.
Differential Revision: https://reviews.llvm.org/D109495
This patch considers the CU index entry
when reading the .debug_rnglists.dwo section.
Reviewed By: jankratochvil
Differential Revision: https://reviews.llvm.org/D107456
Implement a new target.process.follow-fork-mode setting to control
LLDB's behavior on fork. If set to 'parent', the forked child is
detached and parent continues being traced. If set to 'child',
the parent is detached and child becomes traced instead.
Differential Revision: https://reviews.llvm.org/D100503
This diff modifies the LLDB server return codes to more accurately reflect usage
error paths. Specifically we always propagate the return codes from the main
entrypoints into GDB remote LLDB server, and platform LLDB server. This way, the
top-level caller of LLDB server will be able to correctly check whether the
executable exited with or without an error.
We additionally modify and extend the associated shell unit tests to expect
nonzero return codes on error conditions.
Test Plan:
LLDB tests pass:
```
ninja check-lldb
```
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D108351
Temporarily remove breakpoints for the duration of vfork, in order
to prevent them from triggering in the child process. Restore them
once the server reports that vfork has finished and it is ready to
resume execution.
Differential Revision: https://reviews.llvm.org/D100267
Temporarily remove breakpoints for the duration of vfork, in order
to prevent them from triggering in the child process. Restore them
once the server reports that vfork has finished and it is ready to
resume execution.
Differential Revision: https://reviews.llvm.org/D100267
Remove software breakpoints from forked processes in order to restore
the original program code before detaching it.
Differential Revision: https://reviews.llvm.org/D100263
Fix D98289 so that it works even for 2nd..nth compilation unit
(.debug_rnglists).
Reviewed By: dblaikie, ikudrin
Differential Revision: https://reviews.llvm.org/D106466
This test is specifying the lldb log channel via `ll""db` which only really works
because the command parser ends up parsing that as `lldb`. Just putting the
channel name in quotes is enough to avoid the lldb command substitution and
doesn't rely on this weird parser behaviour.
Skeleton vs. DWO units mismatch has been fixed in D106270. As they both
have type DWARFUnit it is a bit difficult to debug. So it is better to
make it safe against future changes.
Reviewed By: kimanh, clayborg
Differential Revision: https://reviews.llvm.org/D107659
Some LD_PRELOAD-ed libraries tend to interact badly with --nodefaultlib,
particularly Gentoo sandbox. Do not run this test if LD_PRELOAD is
present in the running environment.
Differential Revision: https://reviews.llvm.org/D107701
When going through the CU entries in the name index,
make sure to compare the name entry's CU
offset against the skeleton CU's offset.
Previously there would be a mismatch, since the
wrong offset was compared, and thus no suitable
entry was found.
Reviewed By: jankratochvil
Differential Revision: https://reviews.llvm.org/D106270
Summary:
In the spirit of https://reviews.llvm.org/D70846, we only return functions with
matching mangled name from Apple/DebugNamesDWARFIndex::GetFunction if
eFunctionNameTypeFull is requested.
This speeds up lookup in the presence of large amount of class methods of the
same name (a typical examples would be constructors of templates with many
instantiations or overloaded operators).
Reviewers: labath, teemperor
Reviewed By: labath, teemperor
Subscribers: aprantl, arphaman, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73191
