Commit Graph

8 Commits

Author SHA1 Message Date
Pavel Labath 28e4942b2c [lldb] Remove FileSpec(FileSpec*) constructor
This constructor was the cause of some pretty weird behavior. Remove it,
and update all code to properly dereference the argument instead.
2019-12-04 10:49:25 +01:00
Pavel Labath 001ecbde11 SymbolVendorELF: Perform build-id lookup even without a debug link
Summary:
The debug link and build-id lookups are two independent ways one can
search for a separate symbol file. However, our implementation in
SymbolVendorELF was tying the two together and refusing to look up the
symbol file based on a build id if the file did not contain a debug
link.

This patch makes it possible to search for the symbol file with
just one of the two methods available. To demonstrate, I split the
build-id-case test into two, so that we test the search using both
methods.

Reviewers: jankratochvil, mgorny, clayborg, espindola, alexshap

Subscribers: emaste, arichardson, MaskRay, lldb-commits

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

llvm-svn: 367994
2019-08-06 08:18:39 +00:00
Jonas Devlieghere 63e5fb76ec [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)
This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style format
strings, instead of formatv-style format strings.

So instead of writing:

  if (log)
    log->Printf("%s\n", str);

You'd write:

  LLDB_LOG(log, "%s\n", str);

This change was done mechanically with the command below. I replaced the
spurious if-checks with vim, since I know how to do multi-line
replacements with it.

  find . -type f -name '*.cpp' -exec \
  sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" +

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

llvm-svn: 366936
2019-07-24 17:56:10 +00:00
Konrad Kleine 248a13057a [lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]

This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.

This is the command I ran and I to fix and format the code base:

```
run-clang-tidy.py \
	-header-filter='.*' \
	-checks='-*,modernize-use-nullptr' \
	-fix ~/dev/llvm-project/lldb/.* \
	-format \
	-style LLVM \
	-p ~/llvm-builds/debug-ninja-gcc
```

NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.

NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.

Reviewers: martong, espindola, shafik, #lldb, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits

Tags: #lldb, #llvm

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

llvm-svn: 361484
2019-05-23 11:14:47 +00:00
Fangrui Song b0e54cbcdf Fix file names in file headers. NFC
llvm-svn: 360554
2019-05-13 04:42:32 +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
Zachary Turner a89ce43cec Resubmit "Don't include UnixSignals.h from Host."
This was reverted because it breaks the GreenDragon bot, but
the reason for the breakage is lost, so I'm resubmitting this
now so we can find out what the problem is.

llvm-svn: 355528
2019-03-06 18:20:23 +00:00
Zachary Turner 80552918a9 Move Host/Symbols.cpp to Symbols/LocateSymbolFile.cpp
Given that we have a target named Symbols, one wonders why a
file named Symbols.cpp is not in this target.  To be clear,
the functions exposed from this file are really focused on
*locating* a symbol file on a given host, which is where the
ambiguity comes in.  However, it makes more sense conceptually
to be in the Symbols target. While some of the specific places
to search for symbol files might change depending on the Host,
this is not inherently true in the same way that, for example,
"accessing the file system" or "starting threads" is
fundamentally dependent on the Host.

PDBs, for example, recently became a reality on non-Windows platforms,
and it's theoretically possible that DSYMs could become a thing on non
MacOSX platforms (maybe in a remote debugging scenario). Other types of
symbol files, such as DWO, DWP, etc have never been tied to any Host
platform anyway.

After this patch, there is only one remaining dependency from
Host to Target.

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

llvm-svn: 355032
2019-02-27 21:42:10 +00:00