aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Object/ModuleSymbolTable.cpp
AgeCommit message (Collapse)AuthorFilesLines
2021-05-23[MC] Refactor MCObjectFileInfo initialization and allow targets to create ↵Philipp Krones1-4/+5
MCObjectFileInfo This makes it possible for targets to define their own MCObjectFileInfo. This MCObjectFileInfo is then used to determine things like section alignment. This is a follow up to D101462 and prepares for the RISCV backend defining the text section alignment depending on the enabled extensions. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D101921
2021-05-05[MC] Untangle MCContext and MCObjectFileInfoPhilipp Krones1-2/+2
This untangles the MCContext and the MCObjectFileInfo. There is a circular dependency between MCContext and MCObjectFileInfo. Currently this dependency also exists during construction: You can't contruct a MOFI without a MCContext without constructing the MCContext with a dummy version of that MOFI first. This removes this dependency during construction. In a perfect world, MCObjectFileInfo wouldn't depend on MCContext at all, but only be stored in the MCContext, like other MC information. This is future work. This also shifts/adds more information to the MCContext making it more available to the different targets. Namely: - TargetTriple - ObjectFileType - SubtargetInfo Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D101462
2020-07-01[ThinLTO] Always parse module level inline asm with At&t dialect (PR46503)Hans Wennborg1-0/+5
clang-cl passes -x86-asm-syntax=intel to the cc1 invocation so that assembly listings produced by the /FA flag are printed in Intel dialect. That flag however should not affect the *parsing* of inline assembly in the program. (See r322652) When compiling normally, AsmPrinter::emitInlineAsm is used for assembling and defaults to At&t dialect. However, when compiling for ThinLTO, the code which parses module level inline asm to find symbols for the symbol table was failing to set the dialect. This patch fixes that. (See the bug for more details.) Differential revision: https://reviews.llvm.org/D82862
2020-01-29Another round of GCC5 fixes.Benjamin Kramer1-1/+2
2019-10-23[Mips] Use appropriate private label prefix based on Mips ABIMirko Brkusanin1-2/+2
MipsMCAsmInfo was using '$' prefix for Mips32 and '.L' for Mips64 regardless of -target-abi option. By passing MCTargetOptions to MCAsmInfo we can find out Mips ABI and pick appropriate prefix. Tags: #llvm, #clang, #lldb Differential Revision: https://reviews.llvm.org/D66795
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
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
2018-12-14[macho] save the SDK version stored in module metadata into the version min andAlex Lorenz1-0/+1
build version load commands in the object file This commit introduces a new metadata node called "SDK Version". It will be set by the frontend to mark the platform SDK (macOS/iOS/etc) version which was used during that particular compilation. This node is used when machine code is emitted, by either saving the SDK version into the appropriate macho load command (version min/build version), or by emitting the assembly for these load commands with the SDK version specified as well. The assembly for both load commands is extended by allowing it to contain the sdk_version X, Y [, Z] trailing directive to represent the SDK version respectively. rdar://45774000 Differential Revision: https://reviews.llvm.org/D55612 llvm-svn: 349119
2018-04-20LowerTypeTests: Propagate symver directivesVlad Tsyrklevich1-32/+49
Summary: This change fixes https://crbug.com/834474, a build failure caused by LowerTypeTests not preserving .symver symbol versioning directives for exported functions. Emit symver information to ThinLTO summary data and then propagate symver directives for exported functions to the merged module. Emitting symver information to the summaries increases the size of intermediate build artifacts for a Chromium build by less than 0.2%. Reviewers: pcc Reviewed By: pcc Subscribers: tejohnson, mehdi_amini, eraman, llvm-commits, eugenis, kcc Differential Revision: https://reviews.llvm.org/D45798 llvm-svn: 330387
2018-03-20Object: Move attribute calculation into RecordStreamer. NFCVitaly Buka1-78/+2
Summary: Preparation for D44274 Reviewers: pcc, espindola Subscribers: hiraditya Differential Revision: https://reviews.llvm.org/D44276 llvm-svn: 327928
2017-08-02Don't pass the code model to MCRafael Espindola1-1/+1
I was surprised to see the code model being passed to MC. After all, it assembles code, it doesn't create it. The one place it is used is in the expansion of .cfi directives to handle .eh_frame being more that 2gb away from the code. As far as I can tell, gnu assembler doesn't even have an option to enable this. Compiling a c file with gcc -mcmodel=large produces a regular looking .eh_frame. This is probably because in practice linker parse and recreate .eh_frames. In llvm this is used because the JIT can place the code and .eh_frame very far apart. Ideally we would fix the jit and delete this option. This is hard. Apart from confusion another problem with the current interface is that most callers pass CodeModel::Default, which is bad since MC has no way to map it to the target default if it actually needed to. This patch then replaces the argument with a boolean with a default value. The vast majority of users don't ever need to look at it. In fact, only CodeGen and llvm-mc use it and llvm-mc just to enable more testing. llvm-svn: 309884
2017-06-06Sort the remaining #include lines in include/... and lib/....Chandler Carruth1-3/+3
I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
2017-04-24[Object] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko1-7/+25
other minor fixes (NFC). llvm-svn: 301275
2017-03-29Add ifunc support to ModuleSymbolTable.Rafael Espindola1-5/+1
Do that by creating a global_values, which is similar to global_objects, but also iterates over aliases and ifuncs. llvm-svn: 299018
2017-03-09Perform symbol binding for .symver versioned symbolsTeresa Johnson1-6/+83
Summary: In a .symver assembler directive like: .symver name, name2@@nodename "name2@@nodename" should get the same symbol binding as "name". While the ELF object writer is updating the symbol binding for .symver aliases before emitting the object file, not doing so when the module inline assembly is handled by the RecordStreamer is causing the wrong behavior in *LTO mode. E.g. when "name" is global, "name2@@nodename" must also be marked as global. Otherwise, the symbol is skipped when iterating over the LTO InputFile symbols (InputFile::Symbol::shouldSkip). So, for example, when performing any *LTO via the gold-plugin, the versioned symbol definition is not recorded by the plugin and passed back to the linker. If the object was in an archive, and there were no other symbols needed from that object, the object would not be included in the final link and references to the versioned symbol are undefined. The llvm-lto2 tests added will give an error about an unused symbol resolution without the fix. Reviewers: rafael, pcc Reviewed By: pcc Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D30485 llvm-svn: 297332
2016-12-01Object: Set SF_Indirect in ModuleSymbolTable.Peter Collingbourne1-0/+2
This lets us remove the last use of IRObjectFile::getSymbolGV() in llvm-nm. Differential Revision: https://reviews.llvm.org/D27076 llvm-svn: 288321
2016-12-01Object: Add SF_Executable symbol flag.Peter Collingbourne1-1/+4
This allows us to remove a few uses of IRObjectFile::getSymbolGV() in llvm-nm. While here change host-dependent logic in llvm-nm to target-dependent logic. Differential Revision: https://reviews.llvm.org/D27075 llvm-svn: 288320
2016-12-01Object: Extract a ModuleSymbolTable class from IRObjectFile.Peter Collingbourne1-0/+184
This class represents a symbol table built from in-memory IR. It provides access to GlobalValues and should only be used if such access is required (e.g. in the LTO implementation). We will eventually change IRObjectFile to read from a bitcode symbol table rather than using ModuleSymbolTable, so it would not be able to expose the module. Differential Revision: https://reviews.llvm.org/D27073 llvm-svn: 288319
generated by cgit v1.1 at 2025-10-03 20:50:14 +0000