Commit Graph

11 Commits

Author SHA1 Message Date
Pavel Labath 1211baa51c Breakpad: Generate unwind plans from STACK CFI records
Summary:
This patch implements the GetUnwindPlan interface (added in the previous
patch) for SymbolFileBreakpad, and uses it to generate unwind plans from
STACK CFI records in breakpad files.

We first perform a light-weight parse of the breakpad in order to build
up a map of regions covered by the unwind info so that we can later jump
to the right record when we need to unwind a specific function.

The actual parsing is relatively straight-forward, as the STACK CFI records
are just another (text) form of the eh_frame unwind instructions, and
the same goes for lldb's UnwindPlans. The newly-introduced
PostfixExpression API is used to convert the breakpad postfix
expressions into DWARF. The generated dwarf expressions are stored in a
BumpPtrAllocator, as the UnwindPlan does not take ownership of the
expression data it references (usually this is static data in an object
file, so special ownership is needed).

At this moment the generated unwind plans aren't used in the actual
unwind machinery (only in the image show-unwind command), but that is
coming in a separate patch.

Reviewers: amccarth, clayborg, markmentovai

Subscribers: aprantl, jasonmolenda, lldb-commits

Differential Revision: https://reviews.llvm.org/D61733

llvm-svn: 360574
2019-05-13 11:25:35 +00:00
Jonas Devlieghere 8b3af63b89 [NFC] Remove ASCII lines from comments
A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.

I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.

Differential revision: https://reviews.llvm.org/D60508

llvm-svn: 358135
2019-04-10 20:48:55 +00:00
Adrian Prantl 0e4c482124 Pass ConstString by value (NFC)
My apologies for the large patch. With the exception of ConstString.h
itself it was entirely produced by sed.

ConstString has exactly one const char * data member, so passing a
ConstString by reference is not any more efficient than copying it by
value. In both cases a single pointer is passed. But passing it by
value makes it harder to accidentally return the address of a local
object.

(This fixes rdar://problem/48640859 for the Apple folks)

Differential Revision: https://reviews.llvm.org/D59030

llvm-svn: 355553
2019-03-06 21:22:25 +00:00
Adrian Prantl 0f30a3b68f Deserialize Clang module search path from DWARF
This patch properly extracts the full submodule path as well as its
search paths from DWARF import decls and passes it on to the
ClangModulesDeclVendor.

rdar://problem/47970144

Differential Revision: https://reviews.llvm.org/D58090

llvm-svn: 353961
2019-02-13 18:10:41 +00:00
Pavel Labath 3f35ab8b30 SymbolFileBreakpad: Add line table support
Summary:
This patch teaches SymbolFileBreakpad to parse the line information in
breakpad files and present it to lldb.

The trickiest question here was what kind of "compile units" to present
to lldb, as there really isn't enough information in breakpad files to
correctly reconstruct those.

A couple of options were considered
- have the entire file be one compile unit
- have one compile unit for each FILE record
- have one compile unit for each FUNC record

The main drawback of the first approach is that all of the files would
be considered "headers" by lldb, and so they wouldn't be searched if
target.inline-breakpoint-strategy=never. The single compile unit would
also be huge, and there isn't a good way to name it.

The second approach will create mostly correct compile units for cpp
files, but it will still be wrong for headers. However, the biggest
drawback here seemed to be the fact that this can cause a compile unit
to change mid-function (for example when a function from another file is
inlined or another file is #included into a function). While I don't
know of any specific thing that would break in this case, it does sound
like a thing that we should avoid.

In the end, we chose the third option, as it didn't seem to have any
major disadvantages, though it was not ideal either. One disadvantage
here is that this generates a large number of compile units, and there
is still a question on how to name it. We chose to simply name it after
the first line record in that function. This should be correct 99.99% of
the time, though it can produce somewhat strange results if the very
first line record comes from an #included file.

Reviewers: clayborg, zturner, lemo, markmentovai

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D56595

llvm-svn: 353404
2019-02-07 13:42:32 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
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
2019-01-19 08:50:56 +00:00
Zachary Turner 576495e67b [SymbolFile] Remove SymbolContext parameter from FindTypes.
This parameter was only ever used with the Module set, and
since a SymbolFile is tied to a module, the parameter turns
out to be entirely unnecessary.  Furthermore, it doesn't make
a lot of sense to ask a caller to ask SymbolFile which is tied
to Module X to find types for Module Y, but that possibility
was open with the previous interface.  By removing this
parameter from the API, it makes it harder to use incorrectly
as well as easier for an implementor to understand what it
needs to do.

llvm-svn: 351133
2019-01-14 22:41:21 +00:00
Zachary Turner c0a246afbe [SymbolFile] Remove the SymbolContext parameter from FindNamespace.
Every callsite was passing an empty SymbolContext, so this parameter
had no effect.  Inside the DWARF implementation of this function,
however, there was one codepath that checked members of the
SymbolContext.  Since no call-sites actually ever used this
functionality, it was essentially dead code, so I've deleted this
code path as well.

llvm-svn: 351132
2019-01-14 22:41:00 +00:00
Zachary Turner ffc1b8fd76 [SymbolFile] Rename ParseFunctionBlocks to ParseBlocksRecursive.
This method took a SymbolContext but only actually cared about the
case where the m_function member was set.  Furthermore, it was
intended to be implemented to parse blocks recursively despite not
documenting this in its name.  So we change the name to indicate
that it should be recursive, while also limiting the function
parameter to be a Function&.  This lets the caller know what is
required to use it, as well as letting new implementers know what
kind of inputs they need to be prepared to handle.

llvm-svn: 351131
2019-01-14 22:40:41 +00:00
Zachary Turner ce386e306d Fix build breaks after the ParseCompileUnit changes.
The addition of SymbolFileBreakpad crossed paths with my change,
so this interface needs to be fixed up as well.

llvm-svn: 350950
2019-01-11 18:35:58 +00:00
Pavel Labath 1cf23e1a37 Introduce SymbolFileBreakpad and use it to fill symtab
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
2019-01-11 11:17:51 +00:00