PDB/func-symbols.test was orignally written for 32bit x86, keeping in
mind cdecl and stdcall calling conventions which does name mangling for
example like adding "_" underscore before function name.
This is only x86 specific but purpose of pointers.test is NOT to test
calling convention.
I have made a minor change to make this test pass on Windows/Arm.
This patch fixes inline-record.test to run on multiple platforms
including Arm/Windows. Test is fixed to expect any value for id
fields of functions and blocks returned by 'image lookup' command.
This field can be any value as it is internally generated id.
This patch renames PDB/calling-conventions.test to calling-conventions-x86.test.
Also restrict it to run only for target-x86*.
This patch also adds a arm specific test PDB/calling-conventions-arm.test which
tests that x86 specifc calling convention decorators are ignored by Arm compiler.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D128678
PDB/pointers.test was orignally written for 32bit x86 keeping in mind
__cdecl and __stdcall calling conventions which does name mangling for
example like adding "_" underscore before function name.
This is only x86 specific but purpose of pointers.test is NOT to test
calling convention.
I am have made a few minor changes to this test which will make it pass
when run on Windows/Arm platform.
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D128668
Because the diagnostic events are processed by the default event handler
in its own thread, tests cannot rely on output ordering. Split stdout
and stderr to make the test reliable again.
The case comes out of how BOLT handles transformation of
DW_AT_low_pc/DW_AT_high_pc into DW_AT_low_pc/DW_AT_high_pc
with latter being 0.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D127889
The setting `plugin.object-file.pe-coff.module-abi` is a string-to-enum
map that allows specifying an ABI to a module name. For example:
ucrtbase.dll=msvc
libstdc++-6.dll=gnu
This allows for debugging a process which mixes both modules built using
the MSVC ABI and modules built using the MinGW ABI.
Depends on D127048
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D127234
This fixes an issue that, when you start lldb or use `target create`
with a program name which is on $PATH, or not specify the .exe suffix of
a program in the working directory on Windows, you get a confusing
error, for example:
(lldb) target create notepad
error: 'C:\WINDOWS\SYSTEM32\notepad.exe' doesn't contain any 'host'
platform architectures: i686, x86_64, i386, i386
Fixes https://github.com/mstorsjo/llvm-mingw/issues/265
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D127436
25c8a061c5739677d2fc0af29a8cc9520207b923 / D127048 added an option
for setting the ABI to GNU.
When an object file is loaded, there's only minimal verification
done for the architecture spec set for it, if the object file only
provides one.
However, for i386 object files, the PECOFF object file plugin
provides two architectures, i386-pc-windows and i686-pc-windows.
This picks a totally different codepath in
TargetList::CreateTargetInternal, where it's treated as a fat
binary. This goes through more verifications to see if the
architectures provided by the object file matches what the
platform plugin supports.
The PlatformWindows() constructor explicitly adds the
"i386-pc-windows" and "i686-pc-windows" architectures (even when
running on other architectures), which allows this "fat binary
verification" to succeed for the i386 object files that provide
two architectures.
However, after that commit, if the object file is advertised with
the different environment (either when lldb is built in a mingw
environment, or if that setting is set), the fat binary validation
won't accept the file any longer.
Update ArchSpec::IsEqualTo with more logic for the Windows use
cases; mismatching vendors is not an issue (they don't have any
practical effect on Windows), and GNU and MSVC environments are
compatible to the point that PlatformWindows can handle object
files for both environments/ABIs.
As a separate path forward, one could also consider to stop returning
two architecture specs from ObjectFilePECOFF::GetModuleSpecifications
for i386 files.
Differential Revision: https://reviews.llvm.org/D128268
The fix is to append a newline to the source being evaluated.
Without this patch, the following commands **print no output, no errors**.
```
(lldb) script if "foo" in lldb.frame.name: print(lldb.thread)
(lldb) script for f in lldb.thread: print(f.name)
```
The issue is with `code.InteractiveConsole.runsource()`. A trailing newline is
needed for these expressions to be evaluated. I don't know why this is, the
docs don't mention anything.
From a python repl, the following samples show that a terminal newline allows
statements containing flow control to fully execute.
```
>>> import code
>>> repl = code.InteractiveConsole()
>>> repl.runsource("if True: print(1)")
True
>>> repl.runsource("if True: print(1)\n")
1
False
```
Notes:
From an interactive python repl, the output is not printed immediately. The
user is required to enter a blank line following the first.
```
>>> if True: print(1)
...
1
```
However, `python -c 'if True: print(1)'` works without needing a newline.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D127586
The interactive interpreter is overwriting the exit and quit builtins
with an instance of LLDBQuitter in order to make exit and quit behave
like exit() and quit(). It does that by overwriting the __repr__
function to call itself.
Despite being a neat trick, it has the unintentional side effect that
printing these builtins now quits the interpreter:
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> print(exit)
(lldb)
You might consider the above example slightly convoluted, but a more
realistic situation is calling locals():
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> locals()
(lldb)
This patch keeps the existing behavior but without overwriting the
builtins. Instead, it looks for quit and exit in the input. If they're
present, we exit the interpreter with the help of an exception.
The previous implementation also used globals to differentiate between
exit getting called from the interactive interpreter or from inside a
script. This patch achieves the same by using a different exception in
for the interpreter case.
rdar://84095490
Differential revision: https://reviews.llvm.org/D127895
When using the `script` Python repl, SB objects are printed in a way that gives
the user no information. The simplest example is:
```
(lldb) script lldb.debugger
<lldb.SBDebugger; proxy of <Swig Object of type 'lldb::SBDebugger *' at 0x1097a5de0> >
```
This output comes from the Python repl printing the `repr()` of an object.
None of the SB classes implement `__repr__`, and all print like the above.
However, many (most?, all?) SB classes implement `__str__`. Because they
implement `__str__`, a more detailed output can be had by `print`ing the
object, for example:
```
(lldb) script print(lldb.debugger)
Debugger (instance: "debugger_1", id: 1)
```
For convenience, this change switches all SB classes that implement to
`__str__` to instead implement `__repr__`. **The result is that `str()` and
`repr()` will produce the same output**. This is because `str` calls `__repr__`
for classes that have no `__str__` method.
The benefit being that when writing a `script` invocation, you don't need to
remember to wrap in `print()`. If that isn't enough motivation, consider the
case where your Python expression results in a list of SB objects, in that case
you'd have to `map` or use a list comprehension like `[str(x) for x in <expr>]`
in order to see the details of the objects in the list.
For reference, the docs for `repr` say:
> repr(object)
> Return a string containing a printable representation of an object. For
> many types, this function makes an attempt to return a string that would
> yield an object with the same value when passed to eval(); otherwise, the
> representation is a string enclosed in angle brackets that contains the
> name of the type of the object together with additional information often
> including the name and address of the object. A class can control what this
> function returns for its instances by defining a __repr__() method.
and the docs for `__repr__` say:
> object.__repr__(self)
> Called by the repr() built-in function to compute the “official” string
> representation of an object. If at all possible, this should look like a
> valid Python expression that could be used to recreate an object with the
> same value (given an appropriate environment). If this is not possible, a
> string of the form <...some useful description...> should be returned. The
> return value must be a string object. If a class defines __repr__() but not
> __str__(), then __repr__() is also used when an “informal” string
> representation of instances of that class is required.
>
> This is typically used for debugging, so it is important that the
> representation is information-rich and unambiguous.
Even if it were convenient to construct Python expressions for SB classes so
that they could be `eval`'d, however for typical lldb usage, I can't think of a
motivating reason to do so. As it stands, the only action the docs say to do,
that this change doesn't do, is wrap the `repr` string in `<>` angle brackets.
An alternative implementation is to change lldb's python repl to apply `str()`
to the top level result. While this would work well in the case of a single SB
object, it doesn't work for a list of SB objects, since `str([x])` uses `repr`
to convert each list element to a string.
Differential Revision: https://reviews.llvm.org/D127458
This patch changes the `crashlog` command behavior to print the help
message if no argument was provided with the command.
rdar://94576026
Differential Revision: https://reviews.llvm.org/D127362
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
PE/COFF can use either MSVC or GNU (MinGW) ABI for C++ code, however
LLDB had defaulted to MSVC implicitly with no way to override it. This
causes issues when debugging modules built with the GNU ABI, sometimes
even crashes.
This changes the PE/COFF plugin to set the module triple according to
the default target triple used to build LLDB. If the default target
triple is Windows and a valid environment is specified, then this
environment will be used for the module spec. This not only works for
MSVC and GNU, but also other environments.
A new setting, `plugin.object-file.pe-coff.abi`, has been added to
allow overriding this default ABI.
* Fixes https://github.com/llvm/llvm-project/issues/50775
* Fixes https://github.com/mstorsjo/llvm-mingw/issues/226
* Fixes https://github.com/mstorsjo/llvm-mingw/issues/282
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D127048
The specification of gnu-debuglink can be found at:
https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html
The file CRC or the CRC value from the .gnu_debuglink section is now
used to calculate the module UUID as a fallback, to allow verifying that
the debug object does match the executable. Note that if a CodeView
build id exists, it still takes precedence. This works even for MinGW
builds because LLD writes a synthetic CodeView build id which does not
get stripped from the debug object.
The `Minidump/Windows/find-module` test also needs a fix by adding a
CodeView record to the exe to match the one in the minidump, otherwise
it fails due to the new UUID calculated from the file CRC.
Fixes https://github.com/llvm/llvm-project/issues/54344
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D126367
Adds a check to ensure that a process exists before attempting to get
its ABI to prevent lldb from crashing due to trying to read from page zero.
Differential revision: https://reviews.llvm.org/D127016
NativePDB often assumes that all debug info are available.
This is one step to make it more pervasive.
Differential Revision: https://reviews.llvm.org/D125844
plugin to get queried earlier on in the startup, so that for .s files
we call the language "unknown" not "not-loaded". This test was checking
against that string, so I fixed it for the change.
See [[ https://github.com/llvm/llvm-project/issues/55040 | issue 55040 ]] where static members of classes declared in the anonymous namespace are incorrectly returned as member fields from lldb::SBType::GetFieldAtIndex(). It appears that attrs.member_byte_offset contains a sentinel value for members that don't have a DW_AT_data_member_location.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D124409
Currently, ppc64le and ppc64 (defaulting to big endian) have the same
descriptor, thus the linear scan always return ppc64le. Handle that through
subtype.
This is a recommit of f114f009486816ed4b3bf984f0fbbb8fc80914f6 with a new test
setup that doesn't involves (unsupported) corefiles.
Differential Revision: https://reviews.llvm.org/D124760
I suspect that one of link or cl is found by shutil.which
and one isn't, hence the case difference. It doesn't really
matter for what the test is looking for.
This reverts commit d9247cc84825539d346c74eb1379c6cb948d3a71.
With the Windows tests updated to expect .EXE suffixes. This changed
because shutil.which uses PATHEXT which will contain, amongst others,
"EXE".
Also I noticed the "." in ".exe" was the wildcard dot not literal
dot so I've escaped those.
In build.py we have our own find_executable that looks
a lot like the distutils one that I switched to shutil.which.
This find_executable isn't quite the same as shutil.which
so I've refactored it to call that in the correct way.
Note that the path passed to shutil.which is in the form that
PATH would be, meaning separators are allowed.
```
>>> shutil.which("gcc", path="/home/david.spickett:/bin")
'/bin/gcc'
```
We just need to make sure it doesn't ignore the existing PATH
and normalise the result if it does find the binary.
The .exe extension is automatically added to the binary name
if we are on Windows.
Depends on D124601
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D124604
distutils is deprecated and shutil.which is the suggested
replacement for this function.
https://peps.python.org/pep-0632/#migration-advicehttps://docs.python.org/3/library/shutil.html#shutil.which
It was added in Python3.3 but given that we're already using
shutil.which elsewhere I think this is ok/no worse than before.
We do have our own find_executable in lldb/test/Shell/helper/build.py
but I'd rather leave that as is for now. Also we have our own versions
of which() but again, a change for another time.
This work is part of #54337.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D124601
Symbol on-demand feature is never tested on Windows so it is not a surprise
that we are getting Buildbot failure from Windows:
https://lab.llvm.org/buildbot/#/builders/83/builds/18228
This patch disables symbol on-demand feature on Windows. I will find a Windows
machine to test and re-enable symbol on-demand feature as follow-up.
Differential Revision: https://reviews.llvm.org/D124471
This diff introduces a new symbol on-demand which skips
loading a module's debug info unless explicitly asked on
demand. This provides significant performance improvement
for application with dynamic linking mode which has large
number of modules.
The feature can be turned on with:
"settings set symbols.load-on-demand true"
The feature works by creating a new SymbolFileOnDemand class for
each module which wraps the actual SymbolFIle subclass as member
variable. By default, most virtual methods on SymbolFileOnDemand are
skipped so that it looks like there is no debug info for that module.
But once the module's debug info is explicitly requested to
be enabled (in the conditions mentioned below) SymbolFileOnDemand
will allow all methods to pass through and forward to the actual SymbolFile
which would hydrate module's debug info on-demand.
In an internal benchmark, we are seeing more than 95% improvement
for a 3000 modules application.
Currently we are providing several ways to on demand hydrate
a module's debug info:
* Source line breakpoint: matching in supported files
* Stack trace: resolving symbol context for an address
* Symbolic breakpoint: symbol table match guided promotion
* Global variable: symbol table match guided promotion
In all above situations the module's debug info will be on-demand
parsed and indexed.
Some follow-ups for this feature:
* Add a command that allows users to load debug info explicitly while using a
new or existing command when this feature is enabled
* Add settings for "never load any of these executables in Symbols On Demand"
that takes a list of globs
* Add settings for "always load the the debug info for executables in Symbols
On Demand" that takes a list of globs
* Add a new column in "image list" that shows up by default when Symbols On
Demand is enable to show the status for each shlib like "not enabled for
this", "debug info off" and "debug info on" (with a single character to
short string, not the ones I just typed)
Differential Revision: https://reviews.llvm.org/D121631
Added implementation to support DWARF5 in monolithic mode.
Next step DWARF5 split dwarf support.
Reviewed By: maksfb
Differential Revision: https://reviews.llvm.org/D121876
Previously, I was assuming that S_DEFRANGE_SUBFIELD_REGISTERs are always in the
increasing order of offset_in_parent until I saw a counter example.
Using `std::map` so that they are sorted by offset_in_parent.
Differential Revision: https://reviews.llvm.org/D124061
Remove TestShell.test because it's failing on the bot with "this is a
non-interactive debug session, cannot get permission to debug
processes." The only thing that's special about this test is the shell
we're launching with. I need to do a bit of digging to understand why
that's causing this error.
rdar://91766931
When a variable is simple type and has 64 bits, the debug info may look like the following when targeting 32bit windows. The variable's content is split into two 32bits registers.
```
480 | S_LOCAL [size = 12] `x`
type=0x0013 (__int64), flags = param
492 | S_DEFRANGE_SUBFIELD_REGISTER [size = 20]
register = EAX, may have no name = true, offset in parent = 0
range = [0001:0073,+7), gaps = []
512 | S_DEFRANGE_SUBFIELD_REGISTER [size = 20]
register = ECX, may have no name = true, offset in parent = 4
range = [0001:0073,+7), gaps = []
```
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D122943
It fixes the following case:
```
0602 line 1 (+1)
0315 code 0x15 (+0x15)
0B2B code 0x20 (+0xB) line 2 (+1)
0602 line 3 (+1)
0311 code 0x31 (+0x11)
...
```
Inline ranges should have following mapping:
`[0x15, 0x20) -> line 1`
`[0x20, 0x31) -> line 2`
Inline line entries:
`0x15, line 1`, `0x20, line 2`, `0x31, line 3`.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D123092
Port the two Process::PrintWarning functions to use the new diagnostic
events through Debugger::ReportWarning. I kept the wrapper function in
the process, but delegated the work to the Module. Consistent with the
current code, the Module ensures the warning is only printed once per
module.
Differential revision: https://reviews.llvm.org/D123698
Currently, lldb crashes when adding a stop hook with --shlib because we
unconditionally use the target in SymbolContextSpecifier::AddSpecification.
This patch prevents the crash and add a test.
rdar://68524781
Differential revision: https://reviews.llvm.org/D123746
Unlike for any of the other shells, we were escaping $ when using tcsh.
There's nothing special about $ in tcsh and this prevents you from
expanding shell variables, one of the main reasons this functionality
exists in the first place.
Differential revision: https://reviews.llvm.org/D123690
(With C++ exceptions, `clang++ --target=mips64{,el}-linux-gnu -fpie -pie
-fuse-ld=lld` has link errors (lld does not implement some strange R_MIPS_64
.eh_frame handling in GNU ld). However, sanitizer-x86_64-linux-qemu used this to
build ScudoUnitTests. Pined ScudoUnitTests to -no-pie.)
Default the option introduced in D113372 to ON to match all(?) major Linux
distros. This matches GCC and improves consistency with Android and linux-musl
which always default to PIE.
Note: CLANG_DEFAULT_PIE_ON_LINUX may be removed in the future.
Differential Revision: https://reviews.llvm.org/D120305
debugserver does not call thread_set_state when changing xmm/ymm/zmm
register values, so the register contents are never updated. Fix
that. Mark the shell tests which xfail'ed these tests on darwin systems
to xfail them when the system debugserver, they will pass when using
the in-tree debugserver. When this makes it into the installed
system debugservers, we'll remove the xfails.
Differential Revision: https://reviews.llvm.org/D123269
rdar://91258333
rdar://31294382
(The upgrade of the ppc64le bot and D121257 have fixed compiler-rt failures. Tested by nemanjai.)
Default the option introduced in D113372 to ON to match all(?) major Linux
distros. This matches GCC and improves consistency with Android and linux-musl
which always default to PIE.
Note: CLANG_DEFAULT_PIE_ON_LINUX may be removed in the future.
Differential Revision: https://reviews.llvm.org/D120305
