[NFC] This patch fixes URLs containing "master". Old URLs were either broken or
redirecting to the new URL.
Reviewed By: #libc, ldionne, mehdi_amini
Differential Revision: https://reviews.llvm.org/D113186
The amount of roundtrips between StringRefs, ConstStrings and std::strings is
getting a bit out of hand, this patch avoid the unnecessary roundtrips.
Reviewed By: wallace, aprantl
Differential Revision: https://reviews.llvm.org/D112863
The key stored in the source map is a normalized path string with host's
path style, so it is also necessary to normalize the file path during
searching the map
Reviewed By: wallace, aprantl
Differential Revision: https://reviews.llvm.org/D112439
Unqualify (constant) arrays recursively, just like we do for pointers.
This allows for better pretty printer matching.
Differential Revision: https://reviews.llvm.org/D112708
Remove the port predicate from Socket and ConnectionFileDescriptor,
and move it to gdb-remote. It is specifically relevant to the threading
used inside gdb-remote and with the new port callback API, we can
reliably move it there. While at it, switch from the custom Predicate
to std::promise/std::future.
Differential Revision: https://reviews.llvm.org/D112357
Unify the listen and connect code inside lldb-server to use
ConnectionFileDescriptor uniformly rather than a mix of it and Acceptor.
This involves:
- adding a function to map legacy values of host:port parameter
(including legacy server URLs) into CFD-style URLs
- adding a callback to return "local socket id" (i.e. UNIX socket path
or TCP port number) between listen() and accept() calls in CFD
- adding a "unix-abstract-accept" scheme to CFD
As an additional advantage, this permits lldb-server to accept any URL
known to CFD including the new serial:// scheme. Effectively,
lldb-server can now listen on the serial port. Tests for connecting
over a pty are added to test that.
Differential Revision: https://reviews.llvm.org/D111964
Add a Communication::WriteAll() that resumes Write() if the initial call
did not write all data. Use it in GDBRemoteCommunication when sending
packets in order to fix handling partial writes (i.e. just resume/retry
them rather than erring out). This fixes LLDB failures when writing
large packets to a pty.
Differential Revision: https://reviews.llvm.org/D112169
Now that AddRegister() is no longer used, remove it. While at it,
we can also make Finalize() protected as all supported API methods
call it internally.
Differential Revision: https://reviews.llvm.org/D111498
Use llvm::Optional<uint16_t> instead of int for port number
in UriParser::Parse(), and use llvm::None to indicate missing port
instead of a magic value of -1.
Differential Revision: https://reviews.llvm.org/D112309
Add setters for common teletype properties to the Terminal class:
- SetRaw() to enable common raw mode options
- SetBaudRate() to set the baud rate
- SetStopBits() to select the number of stop bits
- SetParity() to control parity bit in the output
- SetHardwareControlFlow() to enable or disable hardware control flow
(if supported)
Differential Revision: https://reviews.llvm.org/D111030
The point is to allow users with a related set of script based commands
to organize their commands in a hierarchy in the command set, rather than
having to have only top-level commands.
Differential Revision: https://reviews.llvm.org/D110298
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
Support specifying an offset for value_regs[0], and add the offset
to the computed derived register offset. This makes it possible to
e.g. create the "ah" register on x86.
Differential Revision: https://reviews.llvm.org/D111489
Add an overload of DynamicRegisterInfo::SetRegisterInfo() that accepts
a std::vector<Register> as an argument. This moves the conversion
from DRI::Register to RegisterInfo directly into DynamicRegisterInfo,
and avoids the necessity of creating fully-compatible intermediate
RegisterInfo instances.
While the new method could technically reuse AddRegister(), the ultimate
goal is to replace AddRegister() with SetRegisterInfo() entirely.
Differential Revision: https://reviews.llvm.org/D111435
Move DynamicRegisterInfo::AddSupplementaryRegister() into a standalone
function working on std::vector<DynamicRegisterInfo::Register>.
Differential Revision: https://reviews.llvm.org/D111295
This adds support for parsing DW_AT_calling_convention in the DWARF parser.
The generic DWARF parsing code already support extracting this attribute from A
DIE and TypeSystemClang already offers a parameter to add a calling convention
to a function type (as the PDB parser supports calling convention parsing), so
this patch just converts the DWARF enum value to the Clang enum value and adds a
few tests.
There are two tests in this patch.:
* A unit test for the added DWARF parsing code that should run on all platforms.
* An API tests that covers the whole expression evaluation machinery by trying
to call functions with non-standard calling conventions. The specific subtests
are target specific as some calling conventions only work on e.g. win32 (or, if
they work on other platforms they only really have observable differences on a
specific target). The tests are also highly compiler-specific, so if GCC or
Clang tell us that they don't support a specific calling convention then we just
skip the test.
Note that some calling conventions are supported by Clang but aren't implemented
in LLVM (e.g. `pascal`), so there we just test that if this ever gets
implemented in LLVM that LLDB works too. There are also some more tricky/obscure
conventions that are left out such as the different swift* conventions, some
planned Obj-C conventions (`Preserve*`), AAPCS* conventions (as the DWARF->Clang
conversion is ambiguous for AAPCS and APPCS-VFP) and conventions only used for
OpenCL etc.
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D108629
This patch adds support for memory regions in Scripted Processes.
This is necessary to read the stack memory region in order to
reconstruct each stackframe of the program.
In order to do so, this patch makes some changes to the SBAPI, namely:
- Add a new constructor for `SBMemoryRegionInfo` that takes arguments
such as the memory region name, address range, permissions ...
This is used when reading memory at some address to compute the offset
in the binary blob provided by the user.
- Add a `GetMemoryRegionContainingAddress` method to `SBMemoryRegionInfoList`
to simplify the access to a specific memory region.
With these changes, lldb is now able to unwind the stack and reconstruct
each frame. On top of that, reloading the target module at offset 0 allows
lldb to symbolicate the `ScriptedProcess` using debug info, similarly to an
ordinary Process.
To test this, I wrote a simple program with multiple function calls, ran it in
lldb, stopped at a leaf function and read the registers values and copied
the stack memory into a binary file. These are then used in the python script.
Differential Revision: https://reviews.llvm.org/D108953
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch introduces the `ScriptedThread` class with its python
interface.
When used with `ScriptedProcess`, `ScriptedThreaad` can provide various
information such as the thread state, stop reason or even its register
context.
This can be used to reconstruct the program stack frames using lldb's unwinder.
rdar://74503836
Differential Revision: https://reviews.llvm.org/D107585
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Open and use the secondary end of a pty for testing Terminal properties
in order to fix the tests on Darwin. While at it, streamline getting
the fd and Terminal class.
Differential Revision: https://reviews.llvm.org/D111402
As discussed in D109948, pre-computing all complex float types is not
necessary and brings extra overhead. This patch removes these defined
types, and construct them in-place when needed.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D111387
The previous version of the patch did not update the definitions in
conditionally compiled code. This patch includes changes to ARC and
windows targets.
Original commit message was:
These were added to support some mips registers on linux, but linux mips
support has now been removed due.
They are still referenced in the freebds mips implementation, but the
completeness of that implementation is also unknown. All other
architectures just set these fields to zero, which is a cause of
significant bloat in our register info definitions.
Arm also has registers with variable sizes, but they were implemented in
a more gdb-compatible fashion and don't use this feature.
Differential Revision: https://reviews.llvm.org/D110914
This has the nice side-effect that it can actually store the quadruple version numbers that Apple's tools are using nowadays.
rdar://82982162
Differential Revision: https://reviews.llvm.org/D111200
This reverts commit 00e704bf08.
This commit should should have updated
llvm/llvm-project/lldb/source/Plugins/ABI/ARC/ABISysV_arc.cpp like the other
architectures.
These were added to support some mips registers on linux, but linux mips
support has now been removed due.
They are still referenced in the freebds mips implementation, but the
completeness of that implementation is also unknown. All other
architectures just set these fields to zero, which is a cause of
significant bloat in our register info definitions.
Arm also has registers with variable sizes, but they were implemented in
a more gdb-compatible fashion and don't use this feature.
Differential Revision: https://reviews.llvm.org/D110914
Move DynamicRegisterInfo from the internal lldbPluginProcessUtility
library to the public lldbTarget library. This is a prerequisite
towards ABI plugin changes that are going to pass DynamicRegisterInfo
parameters.
Differential Revision: https://reviews.llvm.org/D110942
Add a convenience method to add supplementary registers that takes care
of adding invalidate_regs to all (potentially) overlapping registers.
Differential Revision: https://reviews.llvm.org/D110023
Refactor the XML converting attribute and text getters to use LLVM API.
While at it, remove some redundant error and missing XML support
handling, as the called base functions do that anyway. Add tests
for these methods.
Note that this patch changes the getter behavior to be IMHO more
correct. In particular:
- negative and overflowing integers are now reported as failures to
convert, rather than being wrapped over or capped
- digits followed by text are now reported as failures to convert
to double, rather than their numeric part being converted
Differential Revision: https://reviews.llvm.org/D110410
Replace misc. StringConvert uses with llvm::to_integer()
and llvm::to_float(), except for cases where further refactoring is
planned. The purpose of this change is to eliminate the StringConvert
API that is duplicate to LLVM, and less correct in behavior at the same
time.
Differential Revision: https://reviews.llvm.org/D110447
Refactor Socket::DecodeHostAndPort() to use LLVM API over redundant
LLDB API. In particular, this means llvm::Regex, llvm::Error return
type and llvm::to_integer().
While at it, change the port type from int32_t to uint16_t. The method
never returns any value outside this range, and using the correct type
allows us to rely on getAsInteger()'s implicit overflow check.
Differential Revision: https://reviews.llvm.org/D110391
Refactor Socket::DecodeHostAndPort() to use LLVM API over redundant
LLDB API. In particular, this means llvm::Regex, llvm::Error return
type and llvm::to_integer().
While at it, change the port type from int32_t to uint16_t. The method
never returns any value outside this range, and using the correct type
allows us to rely on getAsInteger()'s implicit overflow check.
Differential Revision: https://reviews.llvm.org/D110391
getpeername will return addrlen = 2 (sizeof sa_family_t) for unnamed
sockets (those not assigned a name with bind(2)). This is typically true
for client sockets as well as those created by socketpair(2).
This GetSocketName used to crash for sockets which were connected to
these kinds of sockets. Now it returns an empty string.
Set value_regs and invalidate_regs in RegisterInfo pushed onto m_regs
to nullptr, to ensure that the temporaries passed there are not
accidentally used.
Differential Revision: https://reviews.llvm.org/D109879
I have 2 goals with this change:
1. Disambiguate between CPlusPlus::FindAlternateFunctionManglings and
IRExecutionUnit::FindBestAlternateMangledName. These are named very
similar things, they try to do very similar things, but their
approaches are different. This change should make it clear that one
is generating possible alternate manglings (through some
heuristics-based approach) and the other is finding alternate
manglings (through searching the SymbolFile for potential matches).
2. Change GenerateAlternateFunctionManglings from a static method in
CPlusPlusLanguage to a virtual method in Language. This will allow us
to remove a direct use of CPlusPlusLanguage in IRExecutionUnit,
further pushing it to be more general. This change doesn't meet this
goal completely but allows for it to happen later.
Though this doesn't remove IRExecutionUnit's dependency on
CPlusPlusLanguage, it does bring us closer to that goal.
Differential Revision: https://reviews.llvm.org/D109785
In all these years, we haven't found a use for this function (it has
zero callers). Lets just remove the boilerplate.
Differential Revision: https://reviews.llvm.org/D109600
This patch splits the previous `ScriptedProcessPythonInterface` into
multiple specific classes:
1. The `ScriptedInterface` abstract class that carries the interface
instance object and its virtual pure abstract creation method.
2. The `ScriptedPythonInterface` that holds a generic `Dispatch` method that
can be used by various interfaces to call python methods and also keeps a
reference to the Python Script Interpreter instance.
3. The `ScriptedProcessInterface` that describes the base Scripted
Process model with all the methods used in the underlying script.
All these components are used to refactor the `ScriptedProcessPythonInterface`
class, making it more modular.
This patch is also a requirement for the upcoming work on `ScriptedThread`.
Differential Revision: https://reviews.llvm.org/D107521
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Previously, if no column was specified, ResolveSymbolContext would take
the first match returned by FindLineEntryIndexByFileIndex, and reuse it
to find subsequent exact matches. With the introduction of columns, columns
are now considered when matching the line entries.
This leads to a problem if one wants to get all existing line entries
that match that line, since now the column is also used for the exact match.
This way, all line entries are filtered out that have a different
column number, but the same line number.
This patch changes that by ignoring the column information of the first match
if the original request of ResolveSymbolContext was also ignoring it.
Reviewed By: mib
Differential Revision: https://reviews.llvm.org/D108816
Some files still contained the old University of Illinois Open Source
Licence header. This patch replaces that with the Apache 2 with LLVM
Exception licence.
Differential Revision: https://reviews.llvm.org/D107528
Modify OpenOptions enum to open the future path into synchronizing
vFile:open bits with GDB. Currently, LLDB and GDB use different flag
models effectively making it impossible to match bits. Notably, LLDB
uses two bits to indicate read and write status, and uses union of both
for read/write. GDB uses a value of 0 for read-only, 1 for write-only
and 2 for read/write.
In order to future-proof the code for the GDB variant:
1. Add a distinct eOpenOptionReadWrite constant to be used instead
of (eOpenOptionRead | eOpenOptionWrite) when R/W access is required.
2. Rename eOpenOptionRead and eOpenOptionWrite to eOpenOptionReadOnly
and eOpenOptionWriteOnly respectively, to make it clear that they
do not mean to be combined and require update to all call sites.
3. Use the intersection of all three flags when matching against
the three possible values.
This commit does not change the actual bits used by LLDB.
Differential Revision: https://reviews.llvm.org/D106984
lldb_private::DataExtractor contains DataBufferSP m_data_sp which is
relatively expensive to copy (due to multi-threading locking).
llvm::DataExtractor does not have this problem as it uses StringRef
instead.
The copy constructor is explicit as otherwise it is easy to make
unintended modification of a local copy instead of a caller's instance
(D107470 but that is llvm::DataExtractor).
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D107485
The type field is a signed integer.
(https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html)
However it's not packed in the packet in the way
you might think. For example the type -1 should be:
qMemTags:<addr>,<len>:ffffffff
Instead of:
qMemTags:<addr>,<len>:-1
This change makes lldb-server's parsing more strict
and adds more tests to check that we handle negative types
correctly in lldb and lldb-server.
We only support one tag type value at this point,
for AArch64 MTE, which is positive. So this doesn't change
any of those interactions. It just brings us in line with GDB.
Also check that the test target has MTE. Previously
we just checked that we were AArch64 with a toolchain
that supports MTE.
Finally, update the tag type check for QMemTags to use
the same conversion steps that qMemTags now does.
Using static_cast can invoke UB and though we do do a limit
check to avoid this, I think it's clearer with the new method.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D104914
This adds memory tag writing to Process and the
GDB remote code. Supporting work for the
"memory tag write" command. (to follow)
Process WriteMemoryTags is similair to ReadMemoryTags.
It will pack the tags then call DoWriteMemoryTags.
That function will send the QMemTags packet to the gdb-remote.
The QMemTags packet follows the GDB specification in:
https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#General-Query-Packets
Note that lldb-server will be treating partial writes as
complete failures. So lldb doesn't need to handle the partial
write case in any special way.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D105181
Change SetCurrentThread*() logic not to include the zero padding
in PID/TID that was a side effect of 02ef0f5ab4. This should fix
problems caused by sending 64-bit integers to 32-bit servers. Reported
by Ted Woodward.
Differential Revision: https://reviews.llvm.org/D106832
This patch adds the ability to get a DWARFDIE's children as an LLVM range.
This way we can use for range loops to iterate over them and we can use LLVM's
algorithms like `llvm::all_of` to query all children.
The implementation has to do some small shenanigans as the iterator needs to
store a DWARFDIE, but a DWARFDIE container is also a DWARFDIE so it can't return
the iterator by value. I just made the `children` getter a templated function to
avoid the cyclic dependency.
Reviewed By: #lldb, werat, JDevlieghere
Differential Revision: https://reviews.llvm.org/D103172
PackTags is used by to compress tags to go in the QMemTags packet
and be passed to ptrace when writing memory tags.
The behaviour of RepeatTagsForRange matches that described for QMemTags
in the GDB documentation:
https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#General-Query-Packets
In addition, unpacking tags with number of tags 0 now means
do not check that number of tags matches the range.
This will be used by lldb-server to unpack tags before repeating
them to fill the requested range.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D105179
Previously GetMemoryTagManager checked many things in one:
* architecture supports memory tagging
* process supports memory tagging
* memory range isn't inverted
* memory range is all tagged
Since writing follow up patches for tag writing (in review
at the moment) it has become clear that this gets unwieldy
once we add the features needed for that.
It also implies that the memory tag manager is tied to the
range you used to request it with but it is not. It's a per
process object.
Instead:
* GetMemoryTagManager just checks architecture and process.
* Then the MemoryTagManager can later be asked to check a
memory range.
This is better because:
* We don't imply that range and manager are tied together.
* A slightly diferent range calculation for tag writing
doesn't add more code to Process.
* Range checking code can now be unit tested.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D105630
This reverts commit 82a3883715.
The original version had a copy-paste error: using the Interrupt timeout
for the ResumeSynchronous wait, which is clearly wrong. This error would
have been evident with real use, but the interrupt is long enough that it
only caused one testsuite failure (in the Swift fork).
Anyway, I found that mistake and fixed it and checked all the other places
where I had to plumb through a timeout, and added a test with a short
interrupt timeout stepping over a function that takes 3x the interrupt timeout
to complete, so that should detect a similar mistake in the future.
Refactor SetCurrentThread() and SetCurrentThreadForRun() to reduce code
duplication and simplify it. Both methods now call common
SendSetCurrentThreadPacket() that implements the common protocol
exchange part (the only variable is sending `Hg` vs `Hc`) and returns
the selected TID. The logic is rewritten to use a StreamString
instead of snprintf().
A side effect of the change is that thread-id sent is now zero-padded.
However, this should not have practical impact on the server as both
forms are equivalent.
Differential Revision: https://reviews.llvm.org/D100459
This patch implements a slight improvement when debugging across
platforms and remapping source paths that are in a non-native
format. See the unit test for examples.
rdar://79205675
Differential Revision: https://reviews.llvm.org/D104407
These were disabled in 473a3a773e
because they failed on 32 bit platforms. (Arm for sure but I assume
any 32 bit)
This was due to the printf formatter used. These assumed
that types like uint64_t/size_t would be certain size/type and
that changes on 32 bit.
Instead use "z" to print the size_t and PRI<...> formatters
for the addr_t (always uint64_t) and the int32_t.
This adds GDB client support for the qMemTags packet
which reads memory tags. Following the design
which was recently committed to GDB.
https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#General-Query-Packets
(look for qMemTags)
lldb commands will use the new Process methods
GetMemoryTagManager and ReadMemoryTags.
The former takes a range and checks that:
* The current process architecture has an architecture plugin
* That plugin provides a MemoryTagManager
* That the range of memory requested lies in a tagged range
(it will expand it to granules for you)
If all that was true you get a MemoryTagManager you
can give to ReadMemoryTags.
This two step process is done to allow commands to get the
tag manager without having to read tags as well. For example
you might just want to remove a logical tag, or error early
if a range with tagged addresses is inverted.
Note that getting a MemoryTagManager doesn't mean that the process
or a specific memory range is tagged. Those are seperate checks.
Having a tag manager just means this architecture *could* have
a tagging feature enabled.
An architecture plugin has been added for AArch64 which
will return a MemoryTagManagerAArch64MTE, which was added in a
previous patch.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D95602
This adds the MemoryTagManager class and a specialisation
of that class for AArch64 MTE tags. It provides a generic
interface for various tagging operations.
Adding/removing tags, diffing tagged pointers, etc.
Later patches will use this manager to handle memory tags
in generic code in both lldb and lldb-server.
Since it will be used in both, the base class header is in
lldb/Target.
(MemoryRegionInfo is another example of this pattern)
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D97281
LLDB supports having globbing regexes in the process launch arguments that will
be resolved using the user's shell. This requires that we pass the launch args
to the shell and then read back the expanded arguments using LLDB's argdumper
utility.
As the shell will not just expand the globbing regexes but all special
characters, we need to escape all non-globbing charcters such as $, &, <, >,
etc. as those otherwise are interpreted and removed in the step where we expand
the globbing characters. Also because the special characters are shell-specific,
LLDB needs to maintain a list of all the characters that need to be escaped for
each specific shell.
This patch adds the list of special characters that need to be escaped for
`zsh`. Without this patch on systems where `zsh` is the user's shell (like on
all macOS systems) having any of these special characters in your arguments or
path to the binary will cause the process launch to fail. E.g., `lldb -- ./calc
1<2` is failing without this patch. The same happens if the absolute path to
`calc` is in a directory that contains for example parentheses or other special
characters.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D104627
Rust's v0 name mangling scheme [1] is easy to disambiguate from other
name mangling schemes because symbols always start with `_R`. The llvm
Demangle library supports demangling the Rust v0 scheme. Use it to
demangle Rust symbols.
Added unit tests that check simple symbols. Ran LLDB built with this
patch to debug some Rust programs compiled with the v0 name mangling
scheme. Confirmed symbol names were demangled as expected.
Note: enabling the new name mangling scheme requires a nightly
toolchain:
```
$ cat main.rs
fn main() {
println!("Hello world!");
}
$ $(rustup which --toolchain nightly rustc) -Z symbol-mangling-version=v0 main.rs -g
$ /home/asm/hacking/llvm/build/bin/lldb ./main --one-line 'b main.rs:2'
(lldb) target create "./main"
Current executable set to '/home/asm/hacking/llvm/rust/main' (x86_64).
(lldb) b main.rs:2
Breakpoint 1: where = main`main::main + 4 at main.rs:2:5, address = 0x00000000000076a4
(lldb) r
Process 948449 launched: '/home/asm/hacking/llvm/rust/main' (x86_64)
warning: (x86_64) /lib64/libgcc_s.so.1 No LZMA support found for reading .gnu_debugdata section
Process 948449 stopped
* thread #1, name = 'main', stop reason = breakpoint 1.1
frame #0: 0x000055555555b6a4 main`main::main at main.rs:2:5
1 fn main() {
-> 2 println!("Hello world!");
3 }
(lldb) bt
error: need to add support for DW_TAG_base_type '()' encoded with DW_ATE = 0x7, bit_size = 0
* thread #1, name = 'main', stop reason = breakpoint 1.1
* frame #0: 0x000055555555b6a4 main`main::main at main.rs:2:5
frame #1: 0x000055555555b78b main`<fn() as core::ops::function::FnOnce<()>>::call_once((null)=(main`main::main at main.rs:1), (null)=<unavailable>) at function.rs:227:5
frame #2: 0x000055555555b66e main`std::sys_common::backtrace::__rust_begin_short_backtrace::<fn(), ()>(f=(main`main::main at main.rs:1)) at backtrace.rs:125:18
frame #3: 0x000055555555b851 main`std::rt::lang_start::<()>::{closure#0} at rt.rs:49:18
frame #4: 0x000055555556c9f9 main`std::rt::lang_start_internal::hc51399759a90501a [inlined] core::ops::function::impls::_$LT$impl$u20$core..ops..function..FnOnce$LT$A$GT$$u20$for$u20$$RF$F$GT$::call_once::h04259e4a34d07c2f at function.rs:259:13
frame #5: 0x000055555556c9f2 main`std::rt::lang_start_internal::hc51399759a90501a [inlined] std::panicking::try::do_call::hb8da45704d5cfbbf at panicking.rs:401:40
frame #6: 0x000055555556c9f2 main`std::rt::lang_start_internal::hc51399759a90501a [inlined] std::panicking::try::h4beadc19a78fec52 at panicking.rs:365:19
frame #7: 0x000055555556c9f2 main`std::rt::lang_start_internal::hc51399759a90501a [inlined] std::panic::catch_unwind::hc58016cd36ba81a4 at panic.rs:433:14
frame #8: 0x000055555556c9f2 main`std::rt::lang_start_internal::hc51399759a90501a at rt.rs:34:21
frame #9: 0x000055555555b830 main`std::rt::lang_start::<()>(main=(main`main::main at main.rs:1), argc=1, argv=0x00007fffffffcb18) at rt.rs:48:5
frame #10: 0x000055555555b6fc main`main + 28
frame #11: 0x00007ffff73f2493 libc.so.6`__libc_start_main + 243
frame #12: 0x000055555555b59e main`_start + 46
(lldb)
```
[1]: https://github.com/rust-lang/rust/issues/60705
Reviewed By: clayborg, teemperor
Differential Revision: https://reviews.llvm.org/D104054
This adds a basic SB API for creating and stopping traces.
Note: This doesn't add any APIs for inspecting individual instructions. That'd be a more complicated change and it might be better to enhande the dump functionality to output the data in binary format. I'll leave that for a later diff.
This also enhances the existing tests so that they test the same flow using both the command interface and the SB API.
I also did some cleanup of legacy code.
Differential Revision: https://reviews.llvm.org/D103500
DWARF doesn't describe templates itself but only actual template instantiations.
Because of that LLDB has to infer the parameters of the class template
declarations from the actual instantiations when creating the internal Clang AST
from debug info
Because there is no dedicated DIE for the class template, LLDB also creates the
`ClassTemplateDecl` implicitly when parsing a template instantiation. To avoid
creating one ClassTemplateDecls for every instantiation,
`TypeSystemClang::CreateClassTemplateDecl` will check if there is already a
`ClassTemplateDecl` in the requested `DeclContext` and will reuse a found
fitting declaration.
The logic that checks if a found class template fits to an instantiation is
currently just comparing the name of the template. So right now we map
`template<typename T> struct S;` to an instantiation with the values `S<1, 2,
3>` even though they clearly don't belong together.
This causes crashes later on when for example the Itanium mangler's
`TemplateArgManglingInfo::needExactType` method tries to find fitting the class
template parameter that fits to an instantiation value. In the example above it
will try to find the parameter for the value `2` but will just trigger a
boundary check when retrieving the parameter with index 1 from the class
template.
There are two ways we can end up with an instantiation that doesn't fit to a
class template with the same name:
1. We have two TUs with two templates that have the same name and internal
linkage.
2. A forward declared template instantiation is emitted by GCC and Clang
without an empty list of parameter values.
This patch makes the check for whether a class template declaration can be
reused more sophisticated by also comparing whether the parameter values can fit
to the found class template. If we can't find a fitting class template we
justcreate a second class template with the fitting parameters.
Fixes rdar://76592821
Reviewed By: kastiglione
Differential Revision: https://reviews.llvm.org/D100662
Test leaks if we run
tools/lldb/unittests/Host/HostTests without --gtest_filter
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D104091
It seems std::ostringstream ignores NaN signs on Darwin while it prints them on
Linux. This causes that LLDB behaves differently on those platforms which is
both confusing for users and it also means we have to deal with that in our
tests.
This patch manually implements the NaN/Inf printing (which are apparently
implementation defined) to make LLDB print the same thing on all platforms. The
only output difference in practice seems to be that we now print negative NaNs
as `-nan`, but this potentially also changes the output on other systems I
haven't tested this on.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D102845
The added DumpDataExtractorTest uncovered that this is lshifting a negative
integer which upsets ubsan and breaks the sanitizer bot. This patch just
changes the variable we shift to be unsigned and adds a bunch of tests to make
sure this function does what it promises.
This reverts commit bd5751f3d2.
This patch series is causing us to every so often miss switching
the state from eStateRunning to eStateStopped when we get the stop
packet from the debug server.
Reverting till I can figure out how that could be happening.
ProcessGDBRemote plugin layers.
Also fix a bug where if we tried to interrupt, but the ReadPacket
wakeup timer woke us up just after the timeout, we would break out
the switch, but then since we immediately check if the response is
empty & fail if it is, we could end up actually only giving a
small interval to the interrupt.
Differential Revision: https://reviews.llvm.org/D102085
A type system is not guaranteed to have a symbol file. This patch adds null-pointer checks so we don't crash when trying to access a type system's symbol file.
Reviewed By: aprantl, teemperor
Differential Revision: https://reviews.llvm.org/D101539
Fix cases that can crash `SBStructuredData::operator=`.
This happened in a case where `rhs` had a null `SBStructuredDataImpl`.
Differential Revision: https://reviews.llvm.org/D101585
This patch should fix the windows test failure following `3e2ed7440569`.
It makes use of a `SourceLocationSpec` object when resolving a symbol
context from `SymbolFilePDB` file.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch refactors a good part of the code base turning the usual
FileSpec, Line, Column, CheckInlines, ExactMatch arguments into a
SourceLocationSpec object.
This change is required for a following patch that will add handling of the
column line information when doing symbol resolution.
Differential Revision: https://reviews.llvm.org/D100965
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
A source location specifier class that holds a Declaration object containing
a FileSpec with line and column information. The column line is optional.
It also holds search flags that can be fetched by resolvers to look inlined
declarations and/or exact matches.
It describes a specific location in a source file and allows the user
to perform checks and comparaisons between multiple instances of that class.
Differential Revision: https://reviews.llvm.org/D100962
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Quinn Pham