In preparation for eanbling 64bit support in LLDB switching to use llvm::formatv
instead of format MACROs.
Reviewed By: labath, JDevlieghere
Differential Revision: https://reviews.llvm.org/D139955
This is a fairly large changeset, but it can be broken into a few
pieces:
- `llvm/Support/*TargetParser*` are all moved from the LLVM Support
component into a new LLVM Component called "TargetParser". This
potentially enables using tablegen to maintain this information, as
is shown in https://reviews.llvm.org/D137517. This cannot currently
be done, as llvm-tblgen relies on LLVM's Support component.
- This also moves two files from Support which use and depend on
information in the TargetParser:
- `llvm/Support/Host.{h,cpp}` which contains functions for inspecting
the current Host machine for info about it, primarily to support
getting the host triple, but also for `-mcpu=native` support in e.g.
Clang. This is fairly tightly intertwined with the information in
`X86TargetParser.h`, so keeping them in the same component makes
sense.
- `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains
the target triple parser and representation. This is very intertwined
with the Arm target parser, because the arm architecture version
appears in canonical triples on arm platforms.
- I moved the relevant unittests to their own directory.
And so, we end up with a single component that has all the information
about the following, which to me seems like a unified component:
- Triples that LLVM Knows about
- Architecture names and CPUs that LLVM knows about
- CPU detection logic for LLVM
Given this, I have also moved `RISCVISAInfo.h` into this component, as
it seems to me to be part of that same set of functionality.
If you get link errors in your components after this patch, you likely
need to add TargetParser into LLVM_LINK_COMPONENTS in CMake.
Differential Revision: https://reviews.llvm.org/D137838
My local build is with -DLLVM_ENABLE_PROJECTS=lldb, but I don't compile
with -DLLDB_ENABLE_PYTHON=True or -DLLDB_ENABLE_LUA=True. This results
in there being no script interpreter.
The test lldb/test/Shell/Breakpoint/breakpoint-command.test has an
implicit dependency on a script interpreter being available.
This patch makes that dependency clear. If you have a script
interpreter, the test gets run, otherwise it gets skipped. This means
that folks (like me) who naively use -DLLVM_ENABLE_PROJECTS=lldb can
continue to run check-all without breakages.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D139463
The test is `UNSUPPORTED: system-linux` so the XFAIL for linux is
redundant.
Part of the project to eliminate special handling for triples in lit
expressions.
Differential Revision: https://reviews.llvm.org/D139734
We're suggesting people use the form of the command that takes an exe_ctx - it
is both more convenient and more correct - since you should not be using
GetSelected{Target, Process, etc.} in commands.
My host compiler is clang version 15.0.0, which uses -std=c11 by
default. The test asserts that the language is 'c99', and so the test
fails locally.
Update the test to be explicit about compiling with 'c99'.
Reviewed By: Eric
Differential Revision: https://reviews.llvm.org/D139461
It's required in following situations:
1. As a base class.
2. As a data member.
3. As an array element type.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D134066
This patch changes app_specific_backtrace_crashlog.test's crashlog file
extension from `ips` to `txt. This should prevent the test from opening
Console.app when being run.
This should also fix a test failure caused by missing symbols.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch fixes app_specific_backtrace_crashlog.test.
It was failing because one of the loaded images was built with
optimization which added a new warning message between the first
`CHECK` and the `CHECK-NEXT`, breaking the expected ordering.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
It can happen that the originator of a crash report doesn't have access
to certain images. When that's the case, ReportCrash won't show the
source info in the crash report stack frames, but only the stack address
and image name.
This patch fixes a bug in the crashlog stackframe parser regular
expression to optionally match the source info group.
rdar://101934135
Differential Revision: https://reviews.llvm.org/D137466
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
For an exception crashlog, the thread backtraces aren't usually very helpful
and instead, developpers look at the "Application Specific Backtrace" that
was generated by `objc_exception_throw`.
LLDB could already parse and symbolicate these Application Specific Backtraces
for regular textual-based crashlog, so this patch adds support to parse them
in JSON crashlogs, and materialize them a HistoryThread extending the
crashed ScriptedThread.
This patch also includes the Application Specific Information messages
as part of the process extended crash information log. To do so, the
ScriptedProcess Python interface has a new GetMetadata method that
returns an arbitrary dictionary with data related to the process.
rdar://93207586
Differential Revision: https://reviews.llvm.org/D126260
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch updates the image_regex_uuid matcher to match null-UUID
images in the plain text crashlog parser.
It updates the regex to match one or more '?' characters or the image
full path.
rdar://100904019
Differential Revision: https://reviews.llvm.org/D135482
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
On Linux the `std::function` behaved differently to that on Darwin.
This patch removes usage of `std::function` in the test but attempts
to retain the test-coverage. We mainly want function types appearing
in the template argument and function argument lists.
Also add a `char const*` overload to one of the test functions to
cover the "format function argument using ValueObject formatter" code-path.
Differential Revision: https://reviews.llvm.org/D137272
Remove the colon from the CHECK line for the output of the file command.
On macOS and Linux, the file command uses a colon as the separator
between the path and the file type, but gnuwin32's file command uses a
semicolon.
Connect the diagnostic events with the diagnostic infrastructure.
- Emit existing diagnostic events (warnings and errors) to the
diagnostic log.
- Introduce a new diagnostic event (info) that's used exclusively for
diagnostic logging and does not get broadcast.
Differential revision: https://reviews.llvm.org/D136648
Add a "diagnostics dump" command to, as the name implies, dump the
diagnostics to disk. The goal of this command is to let the user
generate the diagnostics in case of an issue that doesn't cause the
debugger to crash.
This command is also critical for testing, where we don't want to cause
a crash to emit the diagnostics.
Differential revision: https://reviews.llvm.org/D135622
This patch implements the `GetFunctionDisplayName` API which gets
used by the frame-formatting code to decide how to print a
function name.
Currently this API trivially returns `false`, so we try to parse
the demangled function base-name by hand. We try find the closing
parenthesis by doing a forward scan through the demangled name. However,
for arguments that contain parenthesis (e.g., function pointers)
this would leave garbage in the frame function name.
By re-using the `CPlusPlusLanguage` parser for this we offload the
need to parse function names to a component that knows how to do this
already.
We leave the existing parsing code in `FormatEntity` since it's used
in cases where a language-plugin is not available (and is not
necessarily C++ specific).
**Example**
For following function:
```
int foo(std::function<int(void)> const& func) { return 1; }
```
Before patch:
```
frame #0: 0x000000010000151c a.out`foo(func= Function = bar() )> const&) at sample.cpp:11:49
```
After patch:
```
frame #0: 0x000000010000151c a.out`foo(func= Function = bar() ) at sample.cpp:11:49
```
**Testing**
* Added shell test
It's easy enough to disable the lldb-server build. The lldb-server unit
tests already have logic to disable them if we don't build, so this just
makes it even.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D135825
Previously, lldb mistook fields in anonymous union in a struct as the direct
field of the struct, which causes lldb crashes due to multiple fields sharing
the same offset in a struct. This patch fixes it.
MSVC generated pdb doesn't have the debug info entity representing a anonymous
union in a struct. It looks like the following:
```
struct S {
union {
char c;
int i;
};
};
0x1004 | LF_FIELDLIST [size = 40]
- LF_MEMBER [name = `c`, Type = 0x0070 (char), offset = 0, attrs = public]
- LF_MEMBER [name = `i`, Type = 0x0074 (int), offset = 0, attrs = public]
0x1005 | LF_STRUCTURE [size = 32] `S`
unique name: `.?AUS@@`
vtable: <no type>, base list: <no type>, field list: 0x1004
```
Clang generated pdb is similar, though due to the [[ https://github.com/llvm/llvm-project/issues/57999 | bug ]],
it's not more useful than the debug info above. But that's not very relavent,
lldb should still be able to understand MSVC geneerated pdb.
```
0x1003 | LF_UNION [size = 60] `S::<unnamed-tag>`
unique name: `.?AT<unnamed-type-$S1>@S@@`
field list: <no type>
options: forward ref (= 0x1003) | has unique name | is nested, sizeof 0
0x1004 | LF_FIELDLIST [size = 40]
- LF_MEMBER [name = `c`, Type = 0x0070 (char), offset = 0, attrs = public]
- LF_MEMBER [name = `i`, Type = 0x0074 (int), offset = 0, attrs = public]
- LF_NESTTYPE [name = ``, parent = 0x1003]
0x1005 | LF_STRUCTURE [size = 32] `S`
unique name: `.?AUS@@`
vtable: <no type>, base list: <no type>, field list: 0x1004
options: contains nested class | has unique name, sizeof 4
0x1006 | LF_FIELDLIST [size = 28]
- LF_MEMBER [name = `c`, Type = 0x0070 (char), offset = 0, attrs = public]
- LF_MEMBER [name = `i`, Type = 0x0074 (int), offset = 0, attrs = public]
0x1007 | LF_UNION [size = 60] `S::<unnamed-tag>`
unique name: `.?AT<unnamed-type-$S1>@S@@`
field list: 0x1006
options: has unique name | is nested | sealed, sizeof
```
This patch delays the FieldDecl creation when travesing LF_FIELDLIST so we know
if there are multiple fields are in the same offsets and are able to group them
into different anonymous unions based on offsets. Nested anonymous union will
be flatten into one anonymous union, because we simply don't have that info, but
they are equivalent in terms of union layout.
Differential Revision: https://reviews.llvm.org/D134849
The functionality is fine (we don't run the breakpoint command twice), but this test forgot to call `FileCheck` and isn't checking the same value isn't there twice..
In `ProcessWindows::OnDebuggerConnected` (triggered from
`CREATE_PROCESS_DEBUG_EVENT`), we should always call
`Target::SetExecutableModule` regardless of whether LLDB has already
preloaded the executable modules. `SetExecutableModule` has the side
effect of clearing the module list of the Target, which help make sure
that module #0 is the executable module and the rest of the modules are
listed according to the DLL load order in the process (technically this
has no real consequences but it seems to make more sense anyway.) It
also fixes an issue where the modules preloaded by LLDB will be
duplicated when the debuggee process actually loads the DLL.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D134636
Both LLD and GNU ld write global/static variables to the COFF symbol
table with `IMAGE_SYM_TYPE_NULL` and `IMAGE_SYM_DTYPE_NULL` type. Map
these symbols as 'Data' type in the symtab to allow these symbols to be
used in expressions and printable.
Reviewed By: labath, DavidSpickett
Differential Revision: https://reviews.llvm.org/D134585
Forwarder exports do not point to a real function or variable. Instead
they point to a string describing which DLL and symbol to forward to.
Any imports which uses them will be redirected by the loader
transparently. These symbols do not have much use in LLDB, but keep them
just in case someone find it useful. Also set a synthesized name with
the forwarder string for informational purpose.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D134518
If a symbol is the same as an export symbol, mark it as 'Additional' to
prevent the duplicated symbol from being repeated in some commands (e.g.
`disas -n func`). If the RVA is the same but exported with a different
name, only synchronize the symbol types.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D134426
- Skip dummy/invalid export symbols.
- Make the export ordinal of export symbols visible when dumping the
symtab.
- Stop setting the 'Debug' flag and set the 'External' flag instead to
better match the meaning of export symbols.
- Try to guess the type (code vs data) of the symbol from section flags.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D134265
This reimplements `ObjectFilePECOFF::ParseSymtab` to replace the manual
data extraction with what `COFFObjectFile` already provides. Also use
`SymTab::AddSymbol` instead of resizing the SymTab then assigning each
elements afterwards.
Previously, ParseSymTab loads symbols from both the COFF symbol table
and the export table, but if there are any entries in the export table,
it overwrites all the symbols already loaded from the COFF symbol table.
Due to the change to use AddSymbols, this no longer happens, and so the
SymTab now contains all symbols from both tables as expected.
The export symbols are now ordered by ordinal, instead of by the name
table order.
In its current state, it is possible for symbols in the COFF symbol
table to be duplicated by those in the export table. This behaviour will
be modified in a separate change.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D134196
When running `target module lookup` command, show the name of absolute
symbols. Also fix indentation issue after printing an absolute symbol.
Reviewed By: clayborg, DavidSpickett
Differential Revision: https://reviews.llvm.org/D134516
This adds a line break between each result address in the output of the
lldb command `target modules lookup`. Before this change, a new address
result will be printed on the same line as the summary of the last
result, making the output difficult to view.
Also adds a test for this command.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D134111
If a process has multiple threads, the thread with the stop
info might not be the first one in the thread list.
On Windows, under certain circumstances, processes seem to have
one or more extra threads that haven't been launched by the
executable itself, waiting in NtWaitForWorkViaWorkerFactory. If the
main (stopped) thread isn't the first one in the list (the order
seems nondeterministic), DidProcessStopAbnormally() would return
false prematurely, instead of inspecting later threads.
The main observable effect of DidProcessStopAbnormally() erroneously
returning false, is when running lldb with multiple "-o" parameters
to specify multiple commands to execute on the command line.
After an abnormal stop, lldb would stop executing "-o" parameters
and execute "-k" parameters instead - but due to this issue, it
would instead keep executing "-o" parameters as if there was no
abnormal stop. (If multiple parameters are specified via a script
file via the "-s" option, all of the commands in that file are
executed regardless of whether there's an abnormal stop inbetween.)
Differential Revision: https://reviews.llvm.org/D134037
Before, it returns the outermost blocks if nested blocks have the same
address range. That casuses lldb unable to find variables that are inside
inner blocks.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D133601
These are passing now that the relocation assertion has been removed in
D132954.
Relocations still remain unimplemented though, so it's possible this may
start to fail due to unrelated changes. If that happens very often, we
may just need to disable (skip) the test instead.
I encountered an issue where `p &variable` was finding an incorrect address for
32-bit PIC ELF files loaded into a running process. The problem was that the
R_386_32 ELF relocations were not being applied to the DWARF section, so all
variables in that file were reporting as being at the start of their respective
section. There is an assert that catches this on debug builds, but silently
ignores the issue on non-debug builds.
In this changeset, I added handling for the R_386_32 relocation type to
ObjectFileELF, and a supporting function to ELFRelocation to differentiate
between DT_REL & DT_RELA in ObjectFileELF::ApplyRelocations().
Demonstration of issue:
```
[dmlary@host work]$ cat rel.c
volatile char padding[32] = "make sure var isnt at .data+0";
volatile char var[] = "test";
[dmlary@host work]$ gcc -c rel.c -FPIC -fpic -g -m32
[dmlary@host work]$ lldb ./exec
(lldb) target create "./exec"
Current executable set to '/home/dmlary/src/work/exec' (i386).
(lldb) process launch --stop-at-entry
Process 21278 stopped
* thread #1, name = 'exec', stop reason = signal SIGSTOP
frame #0: 0xf7fdb150 ld-2.17.so`_start
ld-2.17.so`_start:
-> 0xf7fdb150 <+0>: movl %esp, %eax
0xf7fdb152 <+2>: calll 0xf7fdb990 ; _dl_start
ld-2.17.so`_dl_start_user:
0xf7fdb157 <+0>: movl %eax, %edi
0xf7fdb159 <+2>: calll 0xf7fdb140
Process 21278 launched: '/home/dmlary/src/work/exec' (i386)
(lldb) image add ./rel.o
(lldb) image load --file rel.o .text 0x40000000 .data 0x50000000
section '.text' loaded at 0x40000000
section '.data' loaded at 0x50000000
(lldb) image dump symtab rel.o
Symtab, file = rel.o, num_symbols = 13:
Debug symbol
|Synthetic symbol
||Externally Visible
|||
Index UserID DSX Type File Address/Value Load Address Size Flags Name
------- ------ --- --------------- ------------------ ------------------ ------------------ ---------- ----------------------------------
[ 0] 1 SourceFile 0x0000000000000000 0x0000000000000000 0x00000004 rel.c
[ 1] 2 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 2] 3 Invalid 0x0000000000000000 0x50000000 0x0000000000000020 0x00000003
[ 3] 4 Invalid 0x0000000000000025 0x0000000000000000 0x00000003
[ 4] 5 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 5] 6 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 6] 7 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 7] 8 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 8] 9 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 9] 10 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 10] 11 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 11] 12 X Data 0x0000000000000000 0x50000000 0x0000000000000020 0x00000011 padding
[ 12] 13 X Data 0x0000000000000020 0x50000020 0x0000000000000005 0x00000011 var
(lldb) p &var
(volatile char (*)[5]) $1 = 0x50000000
```
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D132954
If we don't add local variables with no location info, when trying to print it,
lldb won't find it in the its parent DeclContext, which makes lldb to spend more
time to search all the way up in DeclContext hierarchy until found same name
variable or failed. Dwarf plugin also add local vars even if they don't have
location info.
Differential Revision: https://reviews.llvm.org/D133626
Removed `GetParentDeclContextForSymbol` as this is not necesssary. We can get
the demangled names from CVSymbol and then using it to create tag decl or
namespace decl. This also fixed a bug when icf applied.
Differential Revision: https://reviews.llvm.org/D133243
This patch makes build helper script build.py to use platform.uname for
machine/architecture detection. Visual studio environment when set using
various batch files like vcvars*.bat set PLATFORM environment variable
however VsDevCmd.bat does not set PLATFORM variable.
Differential Revision: https://reviews.llvm.org/D133011
