This patch introduces a new SBAPI method: `SBModule::IsFileBacked`
As the name suggests, it tells the user if the module's object file is
on disk or in memory.
rdar://68538278
Differential Revision: https://reviews.llvm.org/D118261
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Remove ConstString::StaticMemorySize as it is unused and superseded by
GetMemoryStats. It is referenced in a bunch of doc comments but I don't
really understand why. My best guess it that the comments were
copy-pasted from ConstString::MemorySize() even though it didn't make
sense there either. The implementation of StaticMemorySize was being
called on the MemoryPool, not on the ConstString itself.
Differential revision: https://reviews.llvm.org/D118091
This reverts commit ef82063207.
- It conflicts with the existing llvm::size in STLExtras, which will now
never be called.
- Calling it without llvm:: breaks C++17 compat
This adds an option --show-tags to "memory read".
(lldb) memory read mte_buf mte_buf+32 -f "x" -s8 --show-tags
0x900fffff7ff8000: 0x0000000000000000 0x0000000000000000 (tag: 0x0)
0x900fffff7ff8010: 0x0000000000000000 0x0000000000000000 (tag: 0x1)
Tags are printed on the end of each line, if that
line has any tags associated with it. Meaning that
untagged memory output is unchanged.
Tags are printed based on the granule(s) of memory that
a line covers. So you may have lines with 1 tag, with many
tags, no tags or partially tagged lines.
In the case of partially tagged lines, untagged granules
will show "<no tag>" so that the ordering is obvious.
For example, a line that covers 2 granules where the first
is not tagged:
(lldb) memory read mte_buf-16 mte_buf+16 -l32 -f"x" --show-tags
0x900fffff7ff7ff0: 0x00000000 <...> (tags: <no tag> 0x0)
Untagged lines will just not have the "(tags: ..." at all.
Though they may be part of a larger output that does have
some tagged lines.
To do this I've extended DumpDataExtractor to also print
memory tags where it has a valid execution context and
is asked to print them.
There are no special alignment requirements, simply
use "memory read" as usual. All alignment is handled
in DumpDataExtractor.
We use MakeTaggedRanges to find all the tagged memory
in the current dump, then read all that into a MemoryTagMap.
The tag map is populated once in DumpDataExtractor and re-used
for each subsequently printed line (or recursive call of
DumpDataExtractor, which some formats do).
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D107140
The tag map holds a sparse set of memory tags and allows
you to query ranges for tags.
Granules that do not have tags will be set to llvm::None.
to keep the ordering intact. If there are no tags for the
requested range we'll just return an empty result so that
callers don't need to check that all values are llvm::None.
This will be combined with MemoryTagManager's MakeTaggedRanges:
* MakeTaggedRanges
* Read from all those ranges
* Insert the results into the tag map
* Give the tag map to whatever needs to print tags
Which in this case will be "memory read"/DumpDataExtractor.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D112825
This is to be used when you want to know what subranges
of a larger range have memory tagging. Like MakeTaggedRange
but memory without tags is skipped and you get a list of ranges back.
Will be used later by DumpDataExtractor to show memory tags.
MakeTaggedRanges assumes that the memory regions it is
given are sorted in ascending order and do not overlap.
For the current use case where you get regions from
GetMemoryRegions and are on some Linux like OS, this is
reasonable to assume.
I've used asserts to check those conditions. In future
any API binding will check them up front to prevent a crash.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D112824
This patch makes use of c++ type checking and scoped enums to make
logging statements shorter and harder to misuse.
Defines like LIBLLDB_LOG_PROCESS are replaces with LLDBLog::Process.
Because it now carries type information we do not need to worry about
matching a specific enum value with the right getter function -- the
compiler will now do that for us.
The main entry point for the logging machinery becomes the GetLog
(template) function, which will obtain the correct Log object based on
the enum type. It achieves this through another template function
(LogChannelFor<T>), which must be specialized for each type, and should
return the appropriate channel object.
This patch also removes the ability to log a message if multiple
categories are enabled simultaneously as it was unused and confusing.
This patch does not actually remove any of the existing interfaces. The
defines and log retrieval functions are left around as wrappers around
the new interfaces. They will be removed in follow-up patch.
Differential Revision: https://reviews.llvm.org/D117490
I considered keeping this change strictly downstream. Since we still
have a bunch of places that check for Python 2, I figured it doesn't
harm to land it upstream and avoid the conflict when I eventually do
remove them (hopefully soon!).
Add statistics about the memory usage of the string pool. I'm
particularly interested in the memory used by the allocator, i.e. the
number of bytes actually used by the allocator it self as well as the
number of bytes allocated through the allocator.
Differential revision: https://reviews.llvm.org/D117914
This patch updates `dummy_scripted_process.py` to report the dummy
thread correctly to reflect the changes introduced by `d3e0f7e`.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch changes the `ScriptedInterface::ErrorWithMessage` method to
make it `static` which makes it easier to call.
The patch also updates its various call sites to reflect this change.
Differential Revision: https://reviews.llvm.org/D117374
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
When listing all the Scripted Threads of a ScriptedProcess, we can see that all
have the thread index set to 1. This is caused by the lldb_private::Thread
constructor, which sets the m_index_id member using the provided thread id `tid`.
Because the call to the super constructor is done before instantiating
the `ScriptedThreadInterface`, lldb can't fetch the thread id from the
script instance, so it uses `LLDB_INVALID_THREAD_ID` instead.
To mitigate this, this patch takes advantage of the `ScriptedThread::Create`
fallible constructor idiom to defer calling the `ScriptedThread` constructor
(and the `Thread` super constructor with it), until we can fetch a valid
thread id `tid` from the `ScriptedThreadInterface`.
rdar://87432065
Differential Revision: https://reviews.llvm.org/D117076
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds Exceptions to the list of supported stop reasons for
Scripted Threads.
The main motivation for this is that breakpoints are triggered as a
special exception class on ARM platforms, so adding it as a stop reason
allows the ScriptedProcess to selected the ScriptedThread that stopped at
a breakpoint (or crashed :p).
rdar://87430376
Differential Revision: https://reviews.llvm.org/D117074
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds support of multiple Scripted Threads in a ScriptedProcess.
This is done by fetching the Scripted Threads info dictionary at every
ScriptedProcess::DoUpdateThreadList and iterate over each element to
create a new ScriptedThread using the object instance, if it was not
already available.
This patch also adds the ability to pass a pointer of a script interpreter
object instance to initialize a ScriptedInterface instead of having to call
the script object initializer in the ScriptedInterface constructor.
This is used to instantiate the ScriptedThreadInterface from the
ScriptedThread constructor, to be able to perform call on that script
interpreter object instance.
Finally, the patch also updates the scripted process test to check for
multiple threads.
rdar://84507704
Differential Revision: https://reviews.llvm.org/D117071
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Since we can have multiple Scripted Threads per Scripted Process, having
only a single ScriptedThreadInterface (with a single object instance)
will cause the method calls to be done on the wrong object.
Instead, this patch creates a separate ScriptedThreadInterface for each
new lldb_private::ScriptedThread to make sure we interact with the right
instance.
rdar://87427911
Differential Revision: https://reviews.llvm.org/D117070
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds a new method to the Scripted Process interface to
retrive a dictionary of Scripted Threads. It uses the thread ID as a key
and the Scripted Thread instance as the value.
This dictionary will be used to create Scripted Threads in lldb and
perform calls to the python scripted thread object.
rdar://87427126
Differential Revision: https://reviews.llvm.org/D117068
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Only using that change in StringRef already decreases the number of
preoprocessed lines from 7837621 to 7776151 for LLVMSupport
Perhaps more interestingly, it shows that many files were relying on the
inclusion of StringRef.h to have the declaration from STLExtras.h. This
patch tries hard to patch relevant part of llvm-project impacted by this
hidden dependency removal.
Potential impact:
- "llvm/ADT/StringRef.h" no longer includes <memory>,
"llvm/ADT/Optional.h" nor "llvm/ADT/STLExtras.h"
Related Discourse thread:
https://llvm.discourse.group/t/include-what-you-use-include-cleanup/5831
This removes the non-address bits before we try to use
the addresses.
Meaning that when results are shown, those results won't
show non-address bits either. This follows what "memory read"
has done. On the grounds that non-address bits are a property
of a pointer, not the memory pointed to.
I've added testing and merged the find and read tests into one
file.
Note that there are no API side changes because "memory find"
does not have an equivalent API call.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D117299
Allow users to create aliases for aliases to raw input commands. That probably
sounds convoluted, so here's an example:
```
command alias some-setup env SOMEVAR=SOMEVALUE
```
This an alias based on `env`, which itself is an alias for `_regex-env`.
`_regex-env` is a `command regex` command, which takes raw input.
The above `some-setup` alias fails with:
```
error: Unable to create requested alias.
```
This change allows such aliases to be created. lldb already supports aliases to
aliases for parsed commands.
Differential Revision: https://reviews.llvm.org/D117259
The logic of `g_quiet` was inverted in D26243. This corrects the issue.
Without this, running `log timers enable` produces a high volume of incremental
timer output.
Differential Revision: https://reviews.llvm.org/D117837
The tryLockFor method from raw_fd_sotreamis the sole user of that
header, and it's not referenced in the mono repo. I still chose to keep
it (may be useful for downstream user) but added a transient type that's
forward declared to hold the duration parameter.
Notable changes:
- "llvm/Support/Duration.h" must be included in order to use tryLockFor.
- "llvm/Support/raw_ostream.h" no longer includes <chrono>
This sole change has an interesting impact on the number of processed
line, as measured by:
clang++ -E -Iinclude -I../llvm/include ../llvm/lib/Support/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l
before: 7917500
after: 7835142
Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup/5831
The cleanup was manual, but assisted by "include-what-you-use". It consists in
1. Removing unused forward declaration. No impact expected.
2. Removing unused headers in .cpp files. No impact expected.
3. Removing unused headers in .h files. This removes implicit dependencies and
is generally considered a good thing, but this may break downstream builds.
I've updated llvm, clang, lld, lldb and mlir deps, and included a list of the
modification in the second part of the commit.
4. Replacing header inclusion by forward declaration. This has the same impact
as 3.
Notable changes:
- llvm/Support/TargetParser.h no longer includes llvm/Support/AArch64TargetParser.h nor llvm/Support/ARMTargetParser.h
- llvm/Support/TypeSize.h no longer includes llvm/Support/WithColor.h
- llvm/Support/YAMLTraits.h no longer includes llvm/Support/Regex.h
- llvm/ADT/SmallVector.h no longer includes llvm/Support/MemAlloc.h nor llvm/Support/ErrorHandling.h
You may need to add some of these headers in your compilation units, if needs be.
As an hint to the impact of the cleanup, running
clang++ -E -Iinclude -I../llvm/include ../llvm/lib/Support/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l
before: 8000919 lines
after: 7917500 lines
Reduced dependencies also helps incremental rebuilds and is more ccache
friendly, something not shown by the above metric :-)
Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup/5831
Instrument the SB API with signposts on Darwin. This gives us a time
profile on whose behalf LLDB spends time (particularly when run via the
SBAPI from an IDE).
Differential revision: https://reviews.llvm.org/D117632
Remove the last remaining references to the reproducers from the
instrumentation. This patch renames the relevant files and macros.
Differential revision: https://reviews.llvm.org/D117712
I revived lldb-instr to update the macros for D117712. I think the new
macros are simple enough that we add them by hand, but this tool can do
it automatically for you.
Differential revision: https://reviews.llvm.org/D117748
This patch works around what looks like a bug in Clang itself.
The error on the bot is:
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/40466/consoleText
In module 'LLVM_Utils' imported from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/source/Plugins/ScriptInterpreter/Python/lldb-python.h:18:
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/Support/Error.h:720:3: error: 'llvm::Expected<bool>::(anonymous)' from module 'LLVM_Utils.Support.Error' is not present in definition of 'llvm::Expected<bool>' in module 'LLVM_Utils.Support.Error'
union {
^
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/Support/Error.h:720:3: note: declaration of '' does not match
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/Support/Error.h:720:3: note: declaration of '' does not match
1 error generated.
The intention is to revert this as soon as a proper fix has been identified!
rdar://87845391
This enables power-users to annotate lldb api functions with arbitrary
attributes. The motivation for this is being able to build liblldb as a
static library on windows (see discussion on D117564).
This should not be interpreted to mean that building liblldb is
supported in any way, but this does not cause any problems for us, and
can help users who really know what they are doing (or have no other
choice).
Its defaulting logic must go after `project(..)` to work correctly, but `project(..)` is often in a standalone condition making this
awkward, since the rest of the condition code may also need GNUInstallDirs.
The good thing is there are the various standalone booleans, which I had missed before. This makes splitting the conditional blocks less awkward.
Reviewed By: arichardson, phosek, beanz, ldionne, #libunwind, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D117639
Med Ismail Bennani