This patch extends SymbolFileBreakpad::AddSymbols to include the symbols
from the FUNC records too. These symbols come from the debug info and
have a size associated with them, so they are given preference in case
there is a PUBLIC record for the same address.
To achieve this, I first pre-process the symbols into a temporary
DenseMap, and then insert the uniqued symbols into the module's symtab.
Reviewers: clayborg, lemo, zturner
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56590
llvm-svn: 351781
The new LLVM header is one line shorter than the old one, which lead to
some test failures. Ideally tests should rely on line numbers for
breakpoints or output, but that's a different discussion. Hopefully this
turns the bots green again.
llvm-svn: 351779
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
This reapplies commit r351330, which was reverted due to a failing test on
macos. The failure was because the SymbolVendor used on MacOS was stricter than
the default (or ELF) symbol vendor, and rejected the symbol file because it's
UUID did not match the object file.
This version of the patch adds a uuid load command to the test macho file to
make sure the UUIDs match.
llvm-svn: 351447
This reapplies r350802, which was reverted because of issues with
parsing posix-style paths on windows hosts (and vice-versa). These have
since been fixed in r351328, and lldb should now recognise the path
style used in a dwarf compile unit correctly.
llvm-svn: 351435
This patch changes the behavior when printing C++ function references:
where we previously would get a <could not determine size>, there is
now a <no summary available>. It's not clear to me whether this is a
bug or an omission, but it's one step further than LLDB previously
got.
Differential Revision: https://reviews.llvm.org/D56798
llvm-svn: 351376
In this test we have deliberately removed all information which may hint
at the correct path style, so we cannot assert that lldb uses a
particular style. Instead, we should just check that it does something
vaguely reasonable.
llvm-svn: 351359
Summary:
Adding a breakpad symbol file to an existing MachO module with "target symbols
add" currently works only if one's host platform is a mac. This is
because SymbolVendorMacOSX (which is the one responsible for loading
symbols for MachO files) is conditionally compiled for the mac platform.
While we will sooner or later have a special symbol vendor for breakpad
files (to enable more advanced searching), and so this flow could be
made to work through that, it's not clear to me whether this should be a
requirement for the "target symbols add" flow to work. After all, since
the user has explicitly specified the symbol file to use, the symbol
vendor plugin's job is pretty much done.
This patch teaches the default symbol vendor to respect module's symbol
file spec, and load the symbol from that file if it is specified (and no
plugin requests any special handling).
Reviewers: clayborg, zturner, lemo
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56589
llvm-svn: 351330
Summary:
If we opened a file which was produced on system with different path
syntax, we would parse the paths from the debug info incorrectly.
The reason for that is that we would parse the paths as they were
native. For example this meant that on linux we would treat the entire
windows path as a single file name with no directory component, and then
we would concatenate that with the single directory component from the
DW_AT_comp_dir attribute. When parsing posix paths on windows, we would
at least get the directory separators right, but we still would treat
the posix paths as relative, and concatenate them where we shouldn't.
This patch attempts to remedy this by guessing the path syntax used in
each compile unit. (Unfortunately, there is no info in DWARF which would
give the definitive path style used by the produces, so guessing is all
we can do.) Currently, this guessing is based on the DW_AT_comp_dir
attribute of the compile unit, but this can be refined later if needed
(for example, the DW_AT_name of the compile unit may also contain some
useful info). This style is then used when parsing the line table of
that compile unit.
This patch is sufficient to make the line tables come out right, and
enable breakpoint setting by file name work correctly. Setting a
breakpoint by full path still has some kinks (specifically, using a
windows-style full path will not work on linux because the path will be
parsed as a linux path), but this will require larger changes in how
breakpoint setting works.
Reviewers: clayborg, zturner, JDevlieghere
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D56543
llvm-svn: 351328
Summary:
This commit adds the glue code necessary to integrate the
SymbolFileBreakpad into the plugin system. Most of the methods are
stubbed out. The only method implemented method is AddSymbols, which
parses the PUBLIC "section" of the breakpad "object file", and fills out
the Module's symtab.
To enable testing this, I've made two additional changes:
- dump Symtab from the SymbolVendor class. The symtab was already being
dumped as a part of the object file dump, but that happened before
symbol vendor kicked in, so it did not reflect any symbols added
there.
- add ability to explicitly specify the external symbol file in
lldb-test (so that the object file could be linked with the breakpad
symbol file). To make things simpler, I've changed lldb-test from
consuming multiple inputs (and dumping their symbols) to having it
just process a single file per invocation. This was not a problem
since everyone was using it that way already.
Reviewers: clayborg, zturner, lemo, markmentovai, amccarth
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D56173
llvm-svn: 350924
The code was assuming that the elf file will have a PT_LOAD segment
starting from the first byte of the file. While this is true for files
generated by most linkers (it's a way of saving space), it is not a
requirement. And files not satisfying this constraint can still be
perfectly executable. yaml2obj is one of the tools which produces files
like this.
This patch relaxes the check in ObjectFileELF to take the address of the
first PT_LOAD segment as the base address of the object (instead of the
one with the offset 0). Since the PT_LOAD segments are supposed to be
sorted according to the VM address, this entry will also be the one with
the lowest VM address.
If we ever run into files which don't have the PT_LOAD segments sorted,
we can easily change this code to return the lowest VM address as the
base address (if that is the correct thing to do for these files).
llvm-svn: 350923
Typedefs are represented as S_UDT records in the globals stream. This
creates a strange situation where "types" are actually represented as
"symbols", so they need special handling.
In order to test this, we don't just use lldb and print out some
variables causing the AST to get created, because variables whose type
is a typedef will have debug info referencing the original type, not the
typedef. So we use lldb-test instead which will parse all debug info in
the entire file. This exposed some problems with lldb-test and the
native reader, mainly that certain types of obscure symbols which we can
find when iterating every single record would trigger crashes. These
have been fixed as well so that lldb-test can be used to test this
functionality.
Differential Revision: https://reviews.llvm.org/D56461
llvm-svn: 350888
This reverts commit r350802 because the test fails on windows. This
happens because we treat the paths as windows paths even though they
have linux path separators in the asm file. That results in wrong paths
being computed (\tmp\tmp\a.c instead of /tmp/a.c).
Reverting until I can figure out what to do with this.
llvm-svn: 350810
If a section name is exactly 8 bytes long (or has been truncated to 8
bytes), it will not contain the terminating nul character. This means
reading the name as a c string will pick up random data following the
name field (which happens to be the section vm size).
This fixes the name computation to avoid out-of-bounds access and adds a
test.
Reviewers: zturner, stella.stamenova
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56124
llvm-svn: 350809
Summary:
The concept of a base address was already present in the implementation
(it's needed for computing section load addresses properly), but it was
never exposed through this function. This fixes that.
llvm-svn: 350804
Summary:
The motivation for this is being able to write tests for the upcoming
breakpad line table parser, but this could be useful for testing the
low-level workings of any line table format. Or simply for viewing the
line table information with more detail (the brief format doesn't
include any of the flags for end_of_prologue and similar).
I've also removed the load_addresses argument from the
DumpCompileUnitLineTable function, as it wasn't being used anywhere.
Reviewers: clayborg, zturner
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D56315
llvm-svn: 350802
CHECK-DAG can't really be mixed with CHECK-NEXT statements because
each non DAG check sets a new search-origin for following CHECK-DAG
statements. This was passing by coincidence before, but a benign
change in the way we process symbols caused the order of the output
to be different, which triggered this test to fail.
This change makes the test resilient against ordering problems by
running a separate invocation of FileCheck for each function that
we want to test.
Note that with the Native PDB reader, we have full control over
the ordering that symbols are processed in, so we don't have
to worry about different machines returning things in different
orders due to different DIA SDK versions.
llvm-svn: 350773
ParseDeclsForContext was originally created to serve the very specific
case where the context is a function block. It was never intended to be
used for arbitrary DeclContexts, however due to the generic name, the
DWARF and PDB plugins implemented it in this way "just in case". Then,
lldb-test came along and decided to use it in that way.
Related to this, there are a set of functions in the SymbolFile class
interface whose requirements and expectations are not documented. For
example, if you call ParseCompileUnitFunctions, there's an inherent
requirement that you create entries in the underlying clang AST for
these functions as well as their signature types, because in order to
create an lldb_private::Function object, you have to pass it a
CompilerType for the parameter representing the signature.
On the other hand, there is no similar requirement (either inherent or
documented) if one were to call ParseDeclsForContext. Specifically, if
one calls ParseDeclsForContext, and some variable declarations, types,
and other things are added to the clang AST, is it necessary to create
lldb::Variable, lldb::Type, etc objects representing them? Nobody knows.
There is, however, an accidental requirement, because since all of the
plugins implemented this just in case, lldb-test came along and used
ParsedDeclsForContext, and then wrote check lines that depended on this.
When I went to try and implemented the NativePDB reader, I did not
adhere to this (in fact, from a layering perspective I went out of my
way to avoid it), and as a result the existing DIA PDB tests don't work
when the native PDB reader is enabled, because they expect that calling
ParseDeclsForContext will modify the *module's* view of symbols, and not
just the internal AST.
All of this confusion, however, can be avoided if we simply stick to
using ParseDeclsForContext for its original intended use case (blocks),
and use a different function (ParseAllDebugSymbols) for its intended use
case which is, unsuprisingly, to parse all the debug symbols (which is
all lldb-test really wanted to do anyway).
In the future, I would like to change ParseDeclsForContext to
ParseDeclsForFunctionBlock, then delete all of the dead code inside that
handles other types of DeclContexts (and probably even assert if the
DeclContext is anything other than a block).
A few PDB tests needed to be fixed up as a result of this, and this also
exposed a couple of bugs in the DIA PDB reader (doesn't matter much
since it should be going away soon, but worth mentioning) where the
appropriate AST entries weren't being created always.
Differential Revision: https://reviews.llvm.org/D56418
llvm-svn: 350764
Summary:
This is the result of the discussion in D55356, where it was suggested
as a solution to representing the addresses that logically belong to a
module in memory, but are not a part of any of its sections.
The ELF PT_LOAD segments are similar to the MachO "load commands",
except that the relationship between them and the object file sections
is a bit weaker. While in the MachO case, the sections belonging to a
specific segment are placed directly inside it in the object file
logical structur, in the ELF case, the sections and segments form two
separate hierarchies. This means that it is in theory possible to create
an elf file where only a part of a section would belong to some segment
(and another part to a different one). However, I am not aware of any
tool which would produce such a file (and most tools will have problems
ingesting them), so this means it is still possible to follow the MachO
model and make sections children of the PT_LOAD segments.
In case we run into (corrupt?) files with overlapping sections, I have
added code (and tests) which adjusts the sizes and/or drops the offending
sections in order to present a reasonable image to the upper layers of
LLDB. This is mostly done for completeness, as I don't anticipate
running into this situation in the real world. However, if we do run
into it, and the current behavior is not suitable for some reason, we
can implement this logic differently.
Reviewers: clayborg, jankratochvil, krytarowski, joerg, espindola
Subscribers: emaste, arichardson, lldb-commits
Differential Revision: https://reviews.llvm.org/D55998
llvm-svn: 350742
Summary: In standalone builds `LLVM_BINARY_DIR` was equal to `LLDB_BINARY_DIR` so far. This is counterintuitive and invalidated the values of `LLDB_DEFAULT_TEST_DSYMUTIL/FILECHECK/COMPILER` etc.
Reviewers: zturner, labath, clayborg, JDevlieghere, stella.stamenova, serge-sans-paille
Reviewed By: labath
Subscribers: mgorny, friss, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D56443
llvm-svn: 350738
Summary:
In standalone builds of LLDB we currently have no target `count` that tests can depend on. This may be fixed in the future by exporting the target from LLVM similar to targets llvm-config, dsymutil and others.
In-tree build with this patch:
```
$ ninja -t query tools/lldb/lit/check-lldb-lit
tools/lldb/lit/check-lldb-lit:
input: phony
tools/lldb/lit/CMakeFiles/check-lldb-lit
bin/FileCheck
bin/clang
bin/count
bin/darwin-debug
bin/debugserver
bin/dsymutil
bin/llc
bin/lldb
bin/lldb-mi
bin/lldb-server
bin/lldb-test
bin/llvm-config
bin/llvm-mc
bin/llvm-objcopy
bin/not
bin/yaml2obj
lib/liblldb.dylib
projects/libcxx/lib/cxx
tools/lldb/unittests/LLDBUnitTests
outputs:
tools/lldb/test/check-lldb
check-lldb-lit
```
Standalone build with this patch:
```
$ ninja -t query lit/check-lldb-lit
lit/check-lldb-lit:
input: phony
lit/CMakeFiles/check-lldb-lit
bin/darwin-debug
bin/debugserver
bin/lldb
bin/lldb-mi
bin/lldb-server
bin/lldb-test
lib/liblldb.dylib
unittests/LLDBUnitTests
outputs:
test/check-lldb
check-lldb-lit
```
Reviewers: davide, aprantl, JDevlieghere, alexshap
Reviewed By: davide
Subscribers: mgorny, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D56389
llvm-svn: 350538
Summary:
This patch allows ObjectFileBreakpad to parse the contents of Breakpad
files into sections. This sounds slightly odd at first, but in essence
its not too different from how other object files handle things. For
example in elf files, the symtab section consists of a number of
"records", where each record represents a single symbol. The same is
true for breakpad's PUBLIC section, except in this case, the records will be
textual instead of binary.
To keep sections contiguous, I create a new section every time record
type changes. Normally, the breakpad processor will group all records of
the same type in one block, but the format allows them to be intermixed,
so in general, the "object file" may contain multiple sections with the
same record type.
Reviewers: clayborg, zturner, lemo, markmentovai, amccarth
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D55434
llvm-svn: 350511
This is a first step towards getting lldb-test symbols working
with the native plugin. There is a remaining issue, which is
that the plugin expects that ParseDeclsForContext will also
create lldb symbols rather than just the decls, but the native
pdb plugin doesn't currently do this. This will be addressed
in a followup patch.
llvm-svn: 350243
A Previous patch added support for creating VarDecls for global
variables. This patch updates this test to be more strict and
actually check these, not just the types.
llvm-svn: 350242
There were several problems preventing this from working. The
first is that when the PDB had an absolute path to the main
source file, we would construct an invalid path by prepending the
compilation directory to it anyway. So we needed to check if the
path is already absolute first.
Second, LLDB assumes that the zero'th item in the support file list
is the main compilation unit. We were respecting this requirement,
but LLDB *also* requires that file to appear somewhere in the list
starting from index 1 as well. So the main compilation file should
appear in the support file list twice. And when parsing a line
table, it expects the LineEntry records to be constructed using
the 1-based index. With these two fixes we can now set breakpoints
by file and line using the native PDB reader.
llvm-svn: 350240
Summary:
r346165 introduced a bug, where we would fail to parse the size of an
array if that size happened to match an existing die offset.
The logic was:
if (DWARFDIE count = die.GetReferencedDie(DW_AT_count))
num_elements = compute_vla_size(count);
else
num_elements = die.GetUsigned(DW_AT_count); // a fixed-size array
The problem with this logic was that GetReferencedDie did not take the
form class of the attribute into account, and would happily return a die
reference for any form, if its value happened to match some die.
As this behavior is inconsistent with how llvm's DWARFFormValue class
operates, I chose to fix the problem by making our version of this class
match the llvm behavior. For this to work, I had to add an explicit form
class check to the .apple_XXX tables parsing code, because they do
(incorrectly?) use data forms as die references.
Reviewers: aprantl, clayborg
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D55991
llvm-svn: 350086
Previously we would create these for local variables but not for
global variables.
Also updated existing tests which created global variables to check
for them in the resulting AST.
llvm-svn: 349854
Unexpected successes should be considered failures because they can hide
regressions when not addressed. When a test is fixed and not re-enabled,
it can easily regress without us noticing.
I couldn't find a good way to make this change other than changing it in
the unittest2 framework. I know this is less than optimal but since we
have the dependency checked in and the change is pretty fundamental to
the framework I think it's not unreasonable.
Differential revision: https://reviews.llvm.org/D55835
llvm-svn: 349818
This test is now marked as unsupported on Windows - it is not technically "unsupported" on Windows, but it fails because "expr ptr" does not evaluate correctly. However, the error message contains the expected string, so the test "passes" despite the fact that the commands failed
The following bug has been opened for it: llvm.org/pr40119
llvm-svn: 349784
We had a use after free where we were assigning the result of a function
that returned a string to a StringRef. After fixing this use after
free, one of the DIA PDB tests now passes with the native PDB reader,
so we enable the test under native mode as well. The goal is to
eventually make all the tests pass under both, at which point we can
disable them all under DIA mode.
llvm-svn: 349673
The build.py script always runs the compiler in C++ mode, regardless of
the file extension. This results in mangled names presented to the
linker which in turn cannot find the printf symbol.
While we figure out how to solve this issue I've turned the source file
into a cpp file and added extern c. This should unbreak the bots.
llvm-svn: 349642
We reconstruct the AST hierarchy by trying to hack up a mangled
name for the parent type using the child type's mangled name.
This was failing for enums because their tag type is represented
with two letters ("W4") instead of one letter ("T", "U", etc) as
it is with classes, structs, and unions. After accounting for
this we can now correctly determine when an enum is nested
inside of a namespace or a class.
llvm-svn: 349565
