Commit Graph

73 Commits

Author SHA1 Message Date
Adrian Prantl eb200e584e Emit the C++ dialect in -gmodules .pcm files.
Because of commit: https://reviews.llvm.org/D104291 the -gmodules .pcm
files do not have the same DW_AT_language dialect as the .o file. This
was a simple matter of passing the DebugStrictDwarf flag to the
PCHContainerGenerator object's CodeGenOpts from the CompilerInstance
passed in to it.

Before this change if you ran dwarfdump on the gmodule cache folder
you would get DW_AT_language (DW_LANG_C_plus_plus) even when using
-std=c++14 with clang

Patch by Shubham Rastogi!

Differential Revision: https://reviews.llvm.org/D116790
2022-01-10 16:13:40 -08:00
Yuta Saito 1813fde9cc [WebAssembly] Emit clangast in custom section aligned by 4 bytes
Emit __clangast in custom section instead of named data segment
to find it while iterating sections.
This could be avoided if all data segements (the wasm sense) were
represented as their own sections (in the llvm sense).
This can be resolved by https://github.com/WebAssembly/tool-conventions/issues/138

And the on-disk hashtable in clangast needs to be aligned by 4 bytes,
so add paddings in name length field in custom section header.

The length of clangast section name can be represented in 1 byte
by leb128, and possible maximum pads are 3 bytes, so the section
name length won't be invalid in theory.

Fixes https://bugs.llvm.org/show_bug.cgi?id=35928

Differential Revision: https://reviews.llvm.org/D74531
2021-10-19 15:50:08 -07:00
Reid Kleckner 89b57061f7 Move TargetRegistry.(h|cpp) from Support to MC
This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.

This allows us to ensure that Support doesn't have includes from MC/*.

Differential Revision: https://reviews.llvm.org/D111454
2021-10-08 14:51:48 -07:00
Simon Pilgrim b9b90bb542 [clang] Replace report_fatal_error(std::string) uses with report_fatal_error(Twine)
As described on D111049, we're trying to remove the <string> dependency from error handling and replace uses of report_fatal_error(const std::string&) with the Twine() variant which can be forward declared.
2021-10-06 11:43:19 +01:00
Nico Weber 0f1137ba79 [clang/Basic] Make TargetInfo.h not use DataLayout again
Reverts parts of https://reviews.llvm.org/D17183, but keeps the
resetDataLayout() API and adds an assert that checks that datalayout string and
user label prefix are in sync.

Approach 1 in https://reviews.llvm.org/D17183#2653279
Reduces number of TUs build for 'clang-format' from 689 to 575.

I also implemented approach 2 in D100764. If someone feels motivated
to make us use DataLayout more, it's easy to revert this change here
and go with D100764 instead. I don't plan on doing more work in this
area though, so I prefer going with the smaller, more self-consistent change.

Differential Revision: https://reviews.llvm.org/D100776
2021-04-27 22:26:10 -04:00
Zequan Wu 15a3ae1ab1 [Clang] Add __STDCPP_THREADS__ to standard predefine macros
According to https://eel.is/c++draft/cpp.predefined#2.6, `__STDCPP_THREADS__` is a predefined macro.

Differential Revision: https://reviews.llvm.org/D91747
2020-11-22 16:05:53 -08:00
Raphael Isemann 105151ca56 Reland "Correctly emit dwoIDs after ASTFileSignature refactoring (D81347)"
The orignal patch with the missing 'REQUIRES: asserts' as there is a debug-only
flag used in the test.

Original summary:

D81347 changes the ASTFileSignature to be an array of 20 uint8_t instead of 5
uint32_t. However, it didn't update the code in ObjectFilePCHContainerOperations
that creates the dwoID in the module from the ASTFileSignature
(`Buffer->Signature` being the array subclass that is now `std::array<uint8_t,
20>` instead of `std::array<uint32_t, 5>`).

```
  uint64_t Signature = [..] (uint64_t)Buffer->Signature[1] << 32 | Buffer->Signature[0]
```

This code works with the old ASTFileSignature (where two uint32_t are enough to
fill the uint64_t), but after the patch this only took two bytes from the
ASTFileSignature and only partly filled the Signature uint64_t.

This caused that the dwoID in the module ref and the dwoID in the actual module
no longer match (which in turns causes that LLDB keeps warning about the dwoID's
not matching when debugging -gmodules-compiled binaries).

This patch just unifies the logic for turning the ASTFileSignature into an
uint64_t which makes the dwoID match again (and should prevent issues like that
in the future).

Reviewed By: aprantl, dang

Differential Revision: https://reviews.llvm.org/D84013
2020-08-24 14:52:53 +02:00
Raphael Isemann 2b3074c0d1 Revert "Reland "Correctly emit dwoIDs after ASTFileSignature refactoring (D81347)""
This reverts commit ada2e8ea67. Still breaking
on Fuchsia (and also Fedora) with exit code 1, so back to investigating.
2020-08-24 12:54:25 +02:00
Raphael Isemann ada2e8ea67 Reland "Correctly emit dwoIDs after ASTFileSignature refactoring (D81347)"
This relands D84013 but with a test that relies on less shell features to
hopefully make the test pass on Fuchsia (where the test from the previous patch
version strangely failed with a plain "Exit code 1").

Original summary:

D81347 changes the ASTFileSignature to be an array of 20 uint8_t instead of 5 uint32_t.
However, it didn't update the code in ObjectFilePCHContainerOperations that creates
the dwoID in the module from the ASTFileSignature (`Buffer->Signature` being the
array subclass that is now `std::array<uint8_t, 20>` instead of `std::array<uint32_t, 5>`).

```
  uint64_t Signature = [..] (uint64_t)Buffer->Signature[1] << 32 | Buffer->Signature[0]
```

This code works with the old ASTFileSignature  (where two uint32_t are enough to
fill the uint64_t), but after the patch this only took two bytes from the ASTFileSignature
and only partly filled the Signature uint64_t.

This caused that the dwoID in the module ref and the dwoID in the actual module no
longer match (which in turns causes that LLDB keeps warning about the dwoID's not
matching when debugging -gmodules-compiled binaries).

This patch just unifies the logic for turning the ASTFileSignature into an uint64_t which
makes the dwoID match again (and should prevent issues like that in the future).

Reviewed By: aprantl, dang

Differential Revision: https://reviews.llvm.org/D84013
2020-08-24 11:51:32 +02:00
Raphael Isemann c1dd5df425 Revert "Correctly emit dwoIDs after ASTFileSignature refactoring (D81347)"
This reverts commit a4c3ed42ba.

The test is curiously failing with a plain exit code 1 on Fuchsia.
2020-08-21 16:08:37 +02:00
Raphael Isemann a4c3ed42ba Correctly emit dwoIDs after ASTFileSignature refactoring (D81347)
D81347 changes the ASTFileSignature to be an array of 20 uint8_t instead of 5
uint32_t. However, it didn't update the code in ObjectFilePCHContainerOperations
that creates the dwoID in the module from the ASTFileSignature
(`Buffer->Signature` being the array subclass that is now `std::array<uint8_t,
20>` instead of `std::array<uint32_t, 5>`).

```
  uint64_t Signature = [..] (uint64_t)Buffer->Signature[1] << 32 | Buffer->Signature[0]
```

This code works with the old ASTFileSignature (where two uint32_t are enough to
fill the uint64_t), but after the patch this only took two bytes from the
ASTFileSignature and only partly filled the Signature uint64_t.

This caused that the dwoID in the module ref and the dwoID in the actual module
no longer match (which in turns causes that LLDB keeps warning about the dwoID's
not matching when debugging -gmodules-compiled binaries).

This patch just unifies the logic for turning the ASTFileSignature into an
uint64_t which makes the dwoID match again (and should prevent issues like that
in the future).

Reviewed By: aprantl, dang

Differential Revision: https://reviews.llvm.org/D84013
2020-08-21 15:05:02 +02:00
Daniel Grumberg e87e55edbc Make ASTFileSignature an array of 20 uint8_t instead of 5 uint32_t
Reviewers: aprantl, dexonsmith, Bigcheese

Subscribers: arphaman, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D81347
2020-06-11 09:12:29 +01:00
Guillaume Chatelet c79099e0f4 [Alignment][Clang][NFC] Add CharUnits::getAsAlign
Summary:
This is a prerequisite to removing `llvm::GlobalObject::setAlignment(unsigned)`.
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: jholewinski, cfe-commits

Tags: #clang

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

llvm-svn: 373592
2019-10-03 13:00:29 +00:00
Jonas Devlieghere 2b3d49b610 [Clang] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

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

llvm-svn: 368942
2019-08-14 23:04:18 +00:00
George Rimar a11d302fa0 [clang] - An update after LLVM change.
SectionRef::getName() was changed to return Expected<> (D66089)

llvm-svn: 368825
2019-08-14 11:10:01 +00:00
Francis Visoiu Mistrih e0308279cb [Bitcode] Move Bitstream to a separate library
This moves Bitcode/Bitstream*, Bitcode/BitCodes.h to Bitstream/.

This is needed to avoid a circular dependency when using the bitstream
code for parsing optimization remarks.

Since Bitcode uses Core for the IR part:

libLLVMRemarks -> Bitcode -> Core

and Core uses libLLVMRemarks to generate remarks (see
IR/RemarkStreamer.cpp):

Core -> libLLVMRemarks

we need to separate the Bitstream and Bitcode part.

For clang-doc, it seems that it doesn't need the whole bitcode layer, so
I updated the CMake to only use the bitstream part.

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

llvm-svn: 365091
2019-07-03 22:40:07 +00:00
Fangrui Song e183340c29 Recommit [Object] Change object::SectionRef::getContents() to return Expected<StringRef>
r360876 didn't fix 2 call sites in clang.

Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now.

Follow-up of D61781.

llvm-svn: 360892
2019-05-16 13:24:04 +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
Richard Trieu 6368818fd5 Move CodeGenOptions from Frontend to Basic
Basic uses CodeGenOptions and should not depend on Frontend.

llvm-svn: 348827
2018-12-11 03:18:39 +00:00
Richard Trieu 587c1cb9f7 Remove unnecessary include.
llvm-svn: 348459
2018-12-06 06:32:40 +00:00
Adrian Prantl 55fcb4e90e [-gmodules] Honor -fdebug-prefix-map in the debug info inside PCMs.
This patch passes -fdebug-prefix-map (a feature for renaming source
paths in the debug info) through to the per-module codegen options and
adds the debug prefix map to the module hash.

<rdar://problem/46045865>

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

llvm-svn: 347926
2018-11-29 22:33:09 +00:00
Nicola Zaghen 3538b39ed5 [clang] Update uses of DEBUG macro to LLVM_DEBUG.
The DEBUG() macro is very generic so it might clash with other projects.
The renaming was done as follows:
- git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g'
- git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM

Explicitly avoided changing the strings in the clang-format tests.

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

llvm-svn: 332350
2018-05-15 13:30:56 +00:00
Adrian Prantl c5e3647f3c -gmodules: Emit debug info for implicit module imports via #include.
When a type is only used as a template parameter and that type is the
only type imported from another #include'd module, no skeleton CU for
that module is generated, so a consumer doesn't know where to find the
type definition. By emitting an import declaration, we can force a
skeleton CU to be generated for each imported module.

rdar://problem/36266156

llvm-svn: 321754
2018-01-03 19:10:21 +00:00
Adrian Prantl 1b88acedd0 Simplify code (NFC)
llvm-svn: 321750
2018-01-03 18:31:04 +00:00
Adrian Prantl 9a1a1aa2ad Debug Info: Set the MainFileName when generating -gmodules debug info for PCM.
Previously it was uninitialized and thus always defaulted to "<stdin>".
This is mostly a cosmetic change that helps making the debug info more readable.

llvm-svn: 308397
2017-07-18 23:58:34 +00:00
Duncan P. N. Exon Smith 60fa28882e Modules: Use hash of PCM content for SIGNATURE
Change ASTFileSignature from a random 32-bit number to the hash of the
PCM content.

  - Move definition ASTFileSignature to Basic/Module.h so Module and
    ASTSourceDescriptor can use it.

  - Change the signature from uint64_t to std::array<uint32_t,5>.

  - Stop using (saving/reading) the size and modification time of PCM
    files when there is a valid SIGNATURE.

  - Add UNHASHED_CONTROL_BLOCK, and use it to store the SIGNATURE record
    and other records that shouldn't affect the hash.  Because implicit
    modules reuses the same file for multiple levels of -Werror, this
    includes DIAGNOSTIC_OPTIONS and DIAG_PRAGMA_MAPPINGS.

This helps to solve a PCH + implicit Modules dependency issue: PCH files
are handled by the external build system, whereas implicit modules are
handled by internal compiler build system.  This prevents invalidating a
PCH when the compiler overwrites a PCM file with the same content
(modulo the diagnostic differences).

Design and original patch by Manman Ren!

llvm-svn: 297655
2017-03-13 18:45:08 +00:00
Saleem Abdulrasool 888e289ed7 CodeGen: plumb header search down to the IAS
inline assembly may use the `.include` directive to include other
content into the file.  Without the integrated assembler, the `-I` group
gets passed to the assembler.  Emulate this by collecting the header
search paths and passing them to the IAS.

Resolves PR24811!

llvm-svn: 291123
2017-01-05 16:02:32 +00:00
Peter Collingbourne 77c89b6958 Bitcode: Decouple block info block state from reader.
As proposed on llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/106630.html

Move block info block state to a new class, BitstreamBlockInfo.
Clients may set the block info for a particular cursor with the
BitstreamCursor::setBlockInfo() method.

At this point BitstreamReader is not much more than a container for an
ArrayRef<uint8_t>, so remove it and replace all uses with direct uses
of memory buffers.

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

llvm-svn: 286207
2016-11-08 04:17:11 +00:00
Peter Collingbourne 028eb5a3f8 Bitcode: Change reader interface to take memory buffers.
As proposed on llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/106595.html

This change also fixes an API oddity where BitstreamCursor::Read() would
return zero for the first read past the end of the bitstream, but would
report_fatal_error for subsequent reads. Now we always report_fatal_error
for all reads past the end. Updated clients to check for the end of the
bitstream before reading from it.

I also needed to add padding to the invalid bitcode tests in
test/Bitcode/. This is because the streaming interface was not checking that
the file size is a multiple of 4.

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

llvm-svn: 285773
2016-11-02 00:08:19 +00:00
Adrian Prantl 576b2dbec5 Support object-file-wrapped modules in clang -module-file-info.
rdar://problem/24504815

llvm-svn: 279004
2016-08-17 23:13:53 +00:00
Peter Collingbourne 03f8907f65 Frontend: Simplify ownership model for clang's output streams.
This changes the CompilerInstance::createOutputFile function to return
a std::unique_ptr<llvm::raw_ostream>, rather than an llvm::raw_ostream
implicitly owned by the CompilerInstance. This in most cases required that
I move ownership of the output stream to the relevant ASTConsumer.

The motivation for this change is to allow BackendConsumer to be a client
of interfaces such as D20268 which take ownership of the output stream.

Differential Revision: http://reviews.llvm.org/D21537

llvm-svn: 275507
2016-07-15 00:55:40 +00:00
David Majnemer 59f7792136 Use more ArrayRefs
No functional change is intended, just a small refactoring.

llvm-svn: 273647
2016-06-24 04:05:48 +00:00
Benjamin Kramer cfeacf56f0 Apply clang-tidy's misc-move-constructor-init throughout Clang.
No functionality change intended, maybe a tiny performance improvement.

llvm-svn: 270996
2016-05-27 14:27:13 +00:00
David Blaikie af09f4ac72 [modules][debuginfo] Only include imported modules when targeting LLDB
These constructs are only applicable to a debugger capable of loading a
Clang AST, so omit them for brevity when not doing so.

We could potentially propagate more of CodeGenOptions through the
ObjectFilePCGContainerOperations for consistency (so the next person who
adds some CodeGenOpts feature that tweaks debug info output doesn't get
caught by this), so I'm open to objections/alternatives there, but went
with this for now.

Tested just a couple of basic cases (one direct, one indirect (through
the ObjectFilePCHContainerOperations) & fixed up other cases to pass the
-debugger-tuning flag as appropriate.

llvm-svn: 268460
2016-05-03 23:06:40 +00:00
Saleem Abdulrasool 10a4972a8d revert SVN r265702, r265640
Revert the two changes to thread CodeGenOptions into the TargetInfo allocation
and to fix the layering violation by moving CodeGenOptions into Basic.
Code Generation is arguably not particularly "basic".  This addresses Richard's
post-commit review comments.  This change purely does the mechanical revert and
will be followed up with an alternate approach to thread the desired information
into TargetInfo.

llvm-svn: 265806
2016-04-08 16:52:00 +00:00
Saleem Abdulrasool 94cfc603d1 Basic: move CodeGenOptions from Frontend
This is a mechanical move of CodeGenOptions from libFrontend to libBasic.  This
fixes the layering violation introduced earlier by threading CodeGenOptions into
TargetInfo.  It should also fix the modules based self-hosting builds.  NFC.

llvm-svn: 265702
2016-04-07 17:49:44 +00:00
Adrian Prantl 5a9a42778a Module Debugging: Fix a crash when emitting debug info for nested tag types
whose DeclContext is not yet complete by deferring their emission.

rdar://problem/24918680

llvm-svn: 262851
2016-03-07 20:58:52 +00:00
James Y Knight b214cbc785 Make TargetInfo store an actual DataLayout instead of a string.
Use it to calculate UserLabelPrefix, instead of specifying it (often
incorrectly).

Note that the *actual* user label prefix has always come from the
DataLayout, and is handled within LLVM. The main thing clang's
TargetInfo::UserLabelPrefix did was to set the #define value. Having
these be different from each-other is just silly.

Differential Revision: http://reviews.llvm.org/D17183

llvm-svn: 262737
2016-03-04 19:00:41 +00:00
Benjamin Kramer 8c30592e18 Move DebugInfoKind into its own header to cut the cyclic dependency edge from Driver to Frontend.
llvm-svn: 259489
2016-02-02 11:06:51 +00:00
Adrian Prantl 3a2d4947a6 Module Debugging: Canonicalize the file names used as PCH module names
by stripping the path. Follow-up to r258555.

This is safe because only one PCH per CU is currently supported for
module debugging.

rdar://problem/24301262

llvm-svn: 258582
2016-01-22 23:30:56 +00:00
Adrian Prantl aa5d08d04b Module debugging: Create a parent DIModule with the PCH name for types
emitted into a precompiled header to mirror the debug info emitted for
object files importing the PCH.

rdar://problem/24290667

llvm-svn: 258555
2016-01-22 21:14:41 +00:00
Adrian Prantl 98bfc82c39 Fix the build by using the correct suffix for 64 bit literals
llvm-svn: 258531
2016-01-22 19:29:41 +00:00
Adrian Prantl ae108c4704 Fix a typo in r258507 and change the PCH dwoid constant to ~1UL.
rdar://problem/24290667

llvm-svn: 258519
2016-01-22 18:46:45 +00:00
Adrian Prantl c96da8faa6 Module Debugging: Use a nonzero DWO id for precompiled headers.
PCH files don't have a module signature and LLVM uses a nonzero DWO id as
an indicator for skeleton / module CUs. This change pins the DWO id for PCH
files to a known constant value.
The correct long-term solution here is to implement a module signature
that is an actual dterministic hash (at the moment module signatures are
just random nonzero numbers) and then enable this for PCH files as well.

<rdar://problem/24290667>

llvm-svn: 258507
2016-01-22 17:43:43 +00:00
Adrian Prantl cd975018fe Module Debugging: Make sure that anonymous tag decls that define global
variables are visited.

This shouldn't encourage anyone to put global variables into clang modules.
rdar://problem/24199640

llvm-svn: 258250
2016-01-19 23:42:44 +00:00
Adrian Prantl e5238d2a82 Module Debugging: Defer the emission of anonymous tag decls
until we are visiting their declcontext.

This fixes a regression introduced in r256962:
When building debug info for a typdef'd anonymous tag type, we would be
visiting the inner anonymous type first thus creating a "typedef changes
linkage of anonymous type, but linkage was already computed" error.

rdar://problem/24199640

llvm-svn: 258152
2016-01-19 18:02:47 +00:00
Adrian Prantl b3b821f1df Module debugging: Defer emitting tag types until their definition
was visited and all decls have been merged.

We only get a single chance to emit the types for virtual classes because
CGDebugInfo::completeRequiredType() categorically doesn't complete them.

llvm-svn: 256962
2016-01-06 19:22:19 +00:00
Adrian Prantl d43fe0bd39 Module Debugging: Emit module debug info for types inside of Objective-C
containers.

rdar://problem/23196170

llvm-svn: 251120
2015-10-23 17:02:22 +00:00
Adrian Prantl abdd6fc48d Remove a redundant check. NFC
llvm-svn: 251116
2015-10-23 16:51:32 +00:00
Adrian Prantl a5206ce72a Module Debugging: Use the clang module signature as the module's dwo_id
when building a module. Clang already records the module signature when
building a skeleton CU to reference a clang module.

Matching the id in the skeleton with the one in the module allows a DWARF
consumer to verify that they found the correct version of the module
without them needing to know about the clang module format.

llvm-svn: 248345
2015-09-22 23:26:43 +00:00