maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
343,744 Commits 23 Branches 0 Tags 2.2 GiB
C++ 39.1%
LLVM 35.7%
C 12.1%
Assembly 8.9%
Python 1.1%
Other 2.7%
Go to file
Pavel Labath ced45978a2 Recommit "[DWARFDebugLine] Avoid dumping prologue members we did not parse" 
The patch was reverted in 69da40033 because of test failures on windows.
The problem was the unpredictable order of some of the error messages,
which I've tried to strenghten in that patch.

It turns out this is not possible to do in verbose mode because there
the data is being writted as it is being parsed. No amount of flushing
(as I've done in the non-verbose mode) will help that. Indeed, even
without any buffering the warning messages can end in the middle of a
line in non-verbose mode.

In this patch, I have reverted the changes which tested the relative
position of the warning message, except for the messages about
unsupported initial length, which are the ones I really wanted to test,
and which do come out reasonably.

The original commit message was:

This patch if motivated by D74560, specifically the subthread about what
to print upon encountering reserved initial length values.

If the debug_line prologue has an unsupported version, we skip parsing
the rest of the data. If we encounter an reserved initial length field,
we don't even parse the version. However, we still print out all members
(with value 0) in the dump function.

This patch introduces early exits in the Prologue::dump function so that
we print only the fields that were parsed successfully. In case of an
unsupported version, we skip printing all subsequent prologue fields --
because we don't even know if this version has those fields. In case of a
reserved unit length, we don't print anything -- if the very first field
of the prologue is invalid, it's hard to say if we even have a prologue
to begin with.

Note that the user will still be able to see the invalid/reserved
initial length value in the error message. I've modified (reordered)
debug_line_invalid.test to show that the error message comes straight
after the debug_line offset. I've also added some flush() calls to the
dumping code to ensure this is the case in all situations (without that,
the warnings could get out of sync if the output was not a terminal -- I
guess this is why std::iostreams have the tie() function).

Reviewers: jhenderson, ikudrin, dblaikie

Subscribers: hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D75043
 		2020-02-26 16:42:25 +01:00
clang [clang-format] Special handling of spaces for C# code 2020-02-26 15:27:03 +00:00
clang-tools-extra [clangd] use printQualifiedName to skip the inlinenamespace qualifiers. 2020-02-26 16:22:45 +01:00
compiler-rt Revert "[compiler-rt] Add a critical section when flushing gcov counters" 2020-02-26 13:27:44 +01:00
debuginfo-tests [debuginfo-tests] Warn, not error, if we can't delete working directory 2020-02-25 13:15:07 +00:00
libc [libc] [UnitTest] Give UnitTest gtest like colors 2020-02-25 03:46:09 -05:00
libclc libclc: cmake configure should depend on file list 2020-02-25 04:43:14 -05:00
libcxx Remove std::shared_ptr::allocate_shared 2020-02-25 16:50:57 -08:00
libcxxabi [arcconfig] Delete subproject arcconfigs 2020-02-24 16:20:36 -08:00
libunwind [arcconfig] Delete subproject arcconfigs 2020-02-24 16:20:36 -08:00
lld Remove namespace lld { namespace coff { from COFF LLD cpp files 2020-02-25 17:30:53 -08:00
lldb [lldb/gdb-remote] Add support for the qOffsets packet 2020-02-26 10:18:58 +01:00
llvm Recommit "[DWARFDebugLine] Avoid dumping prologue members we did not parse" 2020-02-26 16:42:25 +01:00
mlir [mlir][Linalg] NFC - Refactor LinalgStructuredOps towards "named" Linalg ops 2020-02-26 09:24:38 -05:00
openmp [LIBOMPTARGET]Fix PR44933: fix crash because of the too early deinitialization of libomptarget. 2020-02-25 15:54:37 -05:00
parallel-libs [arcconfig] Delete subproject arcconfigs 2020-02-24 16:20:36 -08:00
polly [polly] Don't count scops in a global variable. 2020-02-24 17:12:08 -08:00
pstl [arcconfig] Delete subproject arcconfigs 2020-02-24 16:20:36 -08:00
.arcconfig [arcconfig] Default base to previous revision 2020-02-24 16:20:25 -08:00
.clang-format
…
.clang-tidy - Update .clang-tidy to ignore parameters of main like functions for naming violations in clang and llvm directory 2020-01-31 16:49:45 +00:00
.git-blame-ignore-revs Add LLDB reformatting to .git-blame-ignore-revs 2019-09-04 09:31:55 +00:00
.gitignore Add a newline at the end of the file 2019-09-04 06:33:46 +00:00
CONTRIBUTING.md Add contributing info to CONTRIBUTING.md and README.md 2019-12-02 15:47:15 +00:00
README.md [README] Add note on using cmake to perform the build 2020-02-12 14:51:24 -06:00

README.md

The LLVM Compiler Infrastructure

This directory and its sub-directories contain source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.

The README briefly describes how to get started with building LLVM. For more information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.

Getting Started with the LLVM System

Taken from https://llvm.org/docs/GettingStarted.html.

Overview

Welcome to the LLVM project!

The LLVM project has multiple components. The core of the project is itself called "LLVM". This contains all of the tools, libraries, and header files needed to process intermediate representations and converts it into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer. It also contains basic regression tests.

C-like languages use the Clang front end. This component compiles C, C++, Objective C, and Objective C++ code into LLVM bitcode -- and from there into object files, using LLVM.

Other components include: the libc++ C++ standard library, the LLD linker, and more.

Getting the Source Code and Building LLVM

The LLVM Getting Started documentation may be out of date. The Clang Getting Started page might have more accurate information.

This is an example work-flow and configuration to get and build the LLVM source:

  1. Checkout LLVM (including related sub-projects like Clang):

    • git clone https://github.com/llvm/llvm-project.git

    • Or, on windows, git clone --config core.autocrlf=false https://github.com/llvm/llvm-project.git

  2. Configure and build LLVM and Clang:

    • cd llvm-project

    • mkdir build

    • cd build

    • cmake -G <generator> [options] ../llvm

      Some common build system generators are:

      • Ninja --- for generating Ninja build files. Most llvm developers use Ninja.
      • Unix Makefiles --- for generating make-compatible parallel makefiles.
      • Visual Studio --- for generating Visual Studio projects and solutions.
      • Xcode --- for generating Xcode projects.

      Some Common options:

      • -DLLVM_ENABLE_PROJECTS='...' --- semicolon-separated list of the LLVM sub-projects you'd like to additionally build. Can include any of: clang, clang-tools-extra, libcxx, libcxxabi, libunwind, lldb, compiler-rt, lld, polly, or debuginfo-tests.

        For example, to build LLVM, Clang, libcxx, and libcxxabi, use -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi".

      • -DCMAKE_INSTALL_PREFIX=directory --- Specify for directory the full path name of where you want the LLVM tools and libraries to be installed (default /usr/local).

      • -DCMAKE_BUILD_TYPE=type --- Valid options for type are Debug, Release, RelWithDebInfo, and MinSizeRel. Default is Debug.

      • -DLLVM_ENABLE_ASSERTIONS=On --- Compile with assertion checks enabled (default is Yes for Debug builds, No for all other build types).

    • cmake --build . [-- [options] <target>] or your build system specified above directly.

      • The default target (i.e. ninja or make) will build all of LLVM.

      • The check-all target (i.e. ninja check-all) will run the regression tests to ensure everything is in working order.

      • CMake will generate targets for each tool and library, and most LLVM sub-projects generate their own check-<project> target.

      • Running a serial build will be slow. To improve speed, try running a parallel build. That's done by default in Ninja; for make, use the option -j NNN, where NNN is the number of parallel jobs, e.g. the number of CPUs you have.

    • For more information see CMake

Consult the Getting Started with LLVM page for detailed information on configuring and compiling LLVM. You can visit Directory Layout to learn about the layout of the source code tree.