According to `/usr/include/elf.h` and `lldb/source/Plugins/ObjectFile/ELF/ELFHeader.h`.
For ELF64 relocation, types of `offset` and `addend` should be `elf_addr` and `elf_sxword`.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D145550
Currently ApplyReloctions() deals with different archs' relocation types
together (in a single `switch() {..}`). I think it is incorrect because
different relocation types of different archs may have same enum values.
For example:
`R_LARCH_32` and `R_X86_64_64` are both `1`;
`R_LARCH_64` and `R_X86_64_PC32` are both `2`.
This patch handles each arch in seperate `switch()` to solve the enum
values conflict issue.
And a new test is added for LoongArch64.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D145462
This patch copies over log files to the diagnostic directory. The caveat
here is that this only works for logs that are redirected to a file. The
implementation piggybacks of the mapping kept by the debugger. The
advantage is that it's free until you generate the diagnostics, at which
point you only pay the price of copying over the file.
Differential revision: https://reviews.llvm.org/D135631
Before this patch, LLDB used to format pointers to members, such as,
```
void (Foo::*pointer_to_member_func)() = &Foo::member_func;
```
as `eFormatBytes`. E.g.,
```
(lldb) v pointer_to_member_func
(void (Foo::*)()) $1 = 94 3f 00 00 01 00 00 00 00 00 00 00 00 00 00 00
```
This patch makes sure we format pointers to member functions the same
way we do regular function pointers.
After this patch we format member pointers as:
```
(lldb) v pointer_to_member_func
(void (Foo::*)()) ::pointer_to_member_func = 0x00000000000000000000000100003f94
```
Differential Revision: https://reviews.llvm.org/D145241
Currently empty arguments are not respected. They are silently dropped
in two places: (1) when extracting them from the target.run-args
setting and (2) when constructing the lldb-argdumper invocation.
(1) is actually a regression from a few years ago. We did not always
drop empty arguments. See 31d97a5c8ab78c619deada0cdb1fcf64021d25dd.
rdar://106279228
Differential Revision: https://reviews.llvm.org/D145450
In an upcoming patch, D142556, Clang is proposed to be changed to emit
line locations that are inlined at line 0. This clashed with the behavior of
GetDIENamesAndRanges() which used 0 as a default value to determine if
file, line or column numbers had been set. Users of that function then
checked for any non-0 values when setting up the call site:
if (call_file != 0 || call_line != 0 || call_column != 0)
[...]
which did not work with the Clang change since all three values then
could be 0.
This changes the function to use std::optional to catch non-set values
instead.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D142552
This came out of from https://discourse.llvm.org/t/dwarf-dwp-4gb-limit/63902
With big binaries we can have .dwp files where .debug_info.dwo section can grow
beyond 4GB. We would like to support this in LLVM and in LLDB.
The plan is to enable manual parsing of cu/tu index in DWARF library
(https://reviews.llvm.org/D137882), and then
switch internal index data structure to 64 bit.
For the second part is to enable 64bit offset support in LLDB with
this patch.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D138618
This came out of from https://discourse.llvm.org/t/dwarf-dwp-4gb-limit/63902
With big binaries we can have .dwp files where .debug_info.dwo section can grow
beyond 4GB. We would like to support this in LLVM and in LLDB.
The plan is to enable manual parsing of cu/tu index in DWARF library
(https://reviews.llvm.org/D137882), and then
switch internal index data structure to 64 bit.
For the second part is to enable 64bit offset support in LLDB with
this patch.
Depends on D139955
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D138618
This came out of from https://discourse.llvm.org/t/dwarf-dwp-4gb-limit/63902
With big binaries we can have .dwp files where .debug_info.dwo section can grow
beyond 4GB. We would like to support this in LLVM and in LLDB.
The plan is to enable manual parsing of cu/tu index in DWARF library
(https://reviews.llvm.org/D137882), and then
switch internal index data structure to 64 bit.
For the second part is to enable 64bit offset support in LLDB with
this patch.
Depends on D139955
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D138618
lldb may crash when performing `image lookup --verbose --address $ADDR`.
The ExecutionContext that gets passed into DWARFExpression::Evaluate may
be valid but unpopulated. However, in one specific case, we were
assuming that it has a valid Target and using it without checking first.
We reach this codepath when we attempt to get information about an
address that doesn't map to a CompileUnit in the module containing the
requested address. lldb then checks to see if it maps to a global
variable, so lldb has to evaluate the location of each global variable
in the module. If a location expression contains DW_OP_deref_size that
uses a FileAddress, we hit this code path. The simplest test case is to
take a module that has a global variable with DW_OP_deref_size in its
location expression, attempt to read an address that doesn't map to a
CompileUnit (e.g. 0x0) and ensure we don't crash.
Differential Revision: https://reviews.llvm.org/D143792
In situations where only LLDB is ASANified, a false positive occurs
unless ASAN_OPTIONS=detect_container_overflow=0 is set in the
environment.
Differential Revision: https://reviews.llvm.org/D143772
Print an error for unsupported combinations of log handlers and log
options. Only the stream log handler takes a file and only the circular
and stream handler take a buffer size. This cannot be dealt with through
option groups because the option combinations depend on the requested
handler.
Differential revision: https://reviews.llvm.org/D143623
When using --name, due to a missing newline, multiple symbol results
were not correctly printed:
```
(lldb) image lookup -r -n "As<.*"
2 matches found in <...>/tbi_lisp:
Address: tbi_lisp<...>
Summary: tbi_lisp<...> at Symbol.cpp:75 Address: tbi_lisp<...>
Summary: tbi_lisp<...> at Symbol.cpp:82
```
It should be:
```
(lldb) image lookup -r -n "As<.*"
2 matches found in /home/david.spickett/tbi_lisp/tbi_lisp:
Address: tbi_lisp<...>
Summary: tbi_lisp<...> at Symbol.cpp:75
Address: tbi_lisp<...>
Summary: tbi_lisp<...> at Symbol.cpp:82
```
With Address/Summary on separate lines.
Reviewed By: clayborg, labath
Differential Revision: https://reviews.llvm.org/D143564
TestFrameFormatNameWithArgs.test is enabled only in case of native
compilation but is applicable in case of cross compilation too. So,
provision support for enabling it in case of both, native and cross
compilation.
Reviewed By: Michael137
Differential Revision: https://reviews.llvm.org/D140839
This fixes a regression introduced by
https://reviews.llvm.org/D131437. The intention of the patch was to
avoid indexing DWO skeleton units, but it also skipped over full DWARF
compile units linked via a -gmodules DW_AT_dwo_name attribute. This
patch restores the functionality and adds a test for it.
Differential Revision: https://reviews.llvm.org/D142683
Reworked after several other major changes to the TargetParser since
this was reverted. Combined with several other changes.
Inline calls for the following macros and delete AArch64TargetParser.def:
AARCH64_ARCH, AARCH64_CPU_NAME, AARCH64_CPU_ALIAS, AARCH64_ARCH_EXT_NAME
Squashed changes from D139278 and D139102.
Differential Revision: https://reviews.llvm.org/D138792
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
