summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Object
Commit message (Collapse)AuthorAgeFilesLines
...
* [BinaryFormat] Teach identify_magic about Tapi files.Cyndy Ishida2019-08-213-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Tapi files are YAML files that start with the !tapi tag. The only execption are TBD v1 files, which don't have a tag. In that case we have to scan a little further and check if the first key "archs" exists. This is the first patch in a series of patches to add libObject support for text-based dynamic library (.tbd) files. This patch is practically exactly the same as D37820, that was never pushed to master, and is needed for future commits related to reading tbd files for llvm-nm Reviewers: ributzka, steven_wu, bollu, espindola, jfb, shafik, jdoerfert Reviewed By: steven_wu Subscribers: dexonsmith, llvm-commits Tags: #llvm, #clang, #sanitizers, #lldb, #libc, #openmp Differential Revision: https://reviews.llvm.org/D66149 llvm-svn: 369579
* Be explicit about Windows coff name trailing character policySerge Guelton2019-08-211-6/+14
| | | | | | | | | | It's okay to *not* copy the trailing zero of a windows section/symbol name. This is compatible with strncpy behavior but gcc doesn't know that and throws an invalid warning. Encode this behavior in a proper function. Differential Revision: https://reviews.llvm.org/D66420 llvm-svn: 369501
* [yaml2obj/obj2yaml][MachO] Allow setting custom section dataSeiya Nuta2019-08-201-1/+6
| | | | | | | | | | | | | | Reviewers: alexshap, jhenderson, rupprecht Reviewed By: alexshap, jhenderson Subscribers: abrachet, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65799 llvm-svn: 369348
* [Object/COFF.h] - Stop returning std::error_code in a few methods. NFCI.George Rimar2019-08-191-23/+0
| | | | | | | | | | There are 4 methods that return std::error_code now, though they do not have to because they are always succeed. I refactored them. This allows to simplify the code in tools a bit. llvm-svn: 369263
* [BPF] Fix bpf llvm-objdump issues.Yonghong Song2019-08-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit https://reviews.llvm.org/D57939 ("[DWARF] Refactor RelocVisitor and fix computation of SHT_RELA-typed relocation entries) made a change for relocation resolution when operating on an object file. The change unfortunately broke BPF as given SymbolValue (S) and Addent (A), previously relocation is resolved to S + A and after the change, it is resolved to S This patch fixed the issue by resolving relocation correctly. It looks not all relocation resolution reaches here and I did not trace down exactly when. But I do find if the object file includes codes in two different ELF sections than default ".text", the above bug will be triggered. This patch included a trivial two function source code to demonstrate this issue. The relocation for .debug_loc is resolved incorrectly due to this and llvm-objdump cannot display source annotated assembly. Differential Revision: https://reviews.llvm.org/D66372 llvm-svn: 369199
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-154-5/+5
| | | | | | | | 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. llvm-svn: 369013
* Recommit r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar2019-08-145-20/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Expected<>" Changes: no changes. A fix for the clang code will be landed right on top. Original commit message: SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368826
* Revert r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar2019-08-145-33/+20
| | | | | | | | Expected<>" It broke clang BB: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/16455 llvm-svn: 368813
* [llvm/Object] - Convert SectionRef::getName() to return Expected<>George Rimar2019-08-145-20/+33
| | | | | | | | | | | | | | | | | | | | | | | SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368812
* [XCOFF] Use a single symbolic constant for the size of an embeded name. [NFC]Sean Fertile2019-08-121-9/+9
| | | | | | | | | | Convert SymbolNameSize and SectionNameSize into just `NameSize`. The length of a name embeded in a symbol table entry or section header table entry is length 8 for Sections, Symbols and Files. No need to have a distinct constant for each one. Also removes the Size argument to 'generateStringRef' as the size is always 'XCOFF::NameSize'. llvm-svn: 368584
* Print reasonable representations of type names in llvm-nm, readelf and readobjSunil Srivastava2019-08-091-1/+10
| | | | | | | | | | | For type values that do not have proper names, print reasonable representation in llvm-nm, llvm-readobj and llvm-readelf, matching GNU tools.s Fixes PR41713. Differential Revision: https://reviews.llvm.org/D65537 llvm-svn: 368451
* Switch LLVM to use 64-bit offsets (2/5)Igor Kudrin2019-08-062-2/+2
| | | | | | | | | This updates all libraries and tools in LLVM Core to use 64-bit offsets which directly or indirectly come to DataExtractor. Differential Revision: https://reviews.llvm.org/D65638 llvm-svn: 368014
* [NFC] Test commit, corrected some spelling in commentDavid Candler2019-08-021-1/+1
| | | | | | | | Test commit, corrected some spelling in comment. Differential Revision: https://reviews.llvm.org/D65516 llvm-svn: 367685
* [Object] Add public MaxSectionAlignment to MachOUniversalShoaib Meenai2019-07-251-6/+7
| | | | | | | | | | | Change MAXSECTALIGN to a public MaxSectionAlignment in MachOUniversal. Will be used in a follow-up. Patch by Anusha Basana <anusha.basana@gmail.com> Differential Revision: https://reviews.llvm.org/D65117 llvm-svn: 366969
* [llvm-ar] Fix support for archives with members larger than 4GBOwen Reynolds2019-07-232-8/+17
| | | | | | | | | | | | | | | | llvm-ar outputs a strange error message when handling archives with members larger than 4GB due to not checking file size when passing the value as an unsigned 32 bit integer. This overflow issue caused malformed archives to be created.: https://bugs.llvm.org/show_bug.cgi?id=38058 This change allows for members above 4GB and will error in a case that is over the formats size limit, a 10 digit decimal integer. Differential Revision: https://reviews.llvm.org/D65093 llvm-svn: 366813
* [Object][XCOFF] Remove extra includes from XCOFF related files. [NFC]Sean Fertile2019-07-221-5/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D60885 llvm-svn: 366723
* [DebugInfo] Generate fixups as emitting DWARF .debug_frame/.eh_frame.Hsiangkai Wang2019-07-191-0/+6
| | | | | | | | | | | | | It is necessary to generate fixups in .debug_frame or .eh_frame as relaxation is enabled due to the address delta may be changed after relaxation. There is an opcode with 6-bits data in debug frame encoding. So, we also need 6-bits fixup types. Differential Revision: https://reviews.llvm.org/D58335 llvm-svn: 366524
* Remove the static initialize introduced in r365099Steven Wu2019-07-181-9/+11
| | | | | | | | | | | | | | | | | | Summary: Some polish for r365099 which adds a static initializer to MachOObjectFile. Remove it by moving it to file scope. Reviewers: smeenai, alexshap, compnerd, mtrent, anushabasana Reviewed By: smeenai Subscribers: hiraditya, jkorous, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64873 llvm-svn: 366496
* Revert "[DebugInfo] Generate fixups as emitting DWARF .debug_frame/.eh_frame."Hsiangkai Wang2019-07-181-6/+0
| | | | | | This reverts commit 17e3cbf5fe656483d9016d0ba9e1d0cd8629379e. llvm-svn: 366444
* [DebugInfo] Generate fixups as emitting DWARF .debug_frame/.eh_frame.Hsiangkai Wang2019-07-181-0/+6
| | | | | | | | | | | | | It is necessary to generate fixups in .debug_frame or .eh_frame as relaxation is enabled due to the address delta may be changed after relaxation. There is an opcode with 6-bits data in debug frame encoding. So, we also need 6-bits fixup types. Differential Revision: https://reviews.llvm.org/D58335 llvm-svn: 366442
* [DWARF][RISCV] Add support for RISC-V relocations needed for debug infoAlex Bradbury2019-07-181-0/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When code relaxation is enabled many RISC-V fixups are not resolved but instead relocations are emitted. This happens even for DWARF debug sections. Therefore, to properly support the parsing of DWARF debug info we need to be able to resolve RISC-V relocations. This patch adds: * Support for RISC-V relocations in RelocationResolver * DWARF support for two relocations per object file offset * DWARF changes to support relocations in more DIE fields The two relocations per offset change is needed because some RISC-V relocations (used for label differences) come in pairs. Relocations can also be emitted for DWARF fields where relocations were not yet evaluated. Adding relocation support for some of these fields is essencial. On the other hand, LLVM currently emits RISC-V relocations for fixups that could be safely evaluated, since they can never be affected by code relaxations. This patch also adds relocation support for the fields affected by those extraneous relocations (the DWARF unit entry Length, and the DWARF debug line entry TotalLength and PrologueLength), for testing purposes. Differential Revision: https://reviews.llvm.org/D62062 Patch by Luís Marques. llvm-svn: 366402
* [Object] isNotObjectErrorInvalidFileType: simplifyFangrui Song2019-07-131-13/+10
| | | | llvm-svn: 365997
* [Object] isNotObjectErrorInvalidFileType: fix use-after-moveFangrui Song2019-07-131-1/+1
| | | | llvm-svn: 365996
* [Support] Move llvm::MemoryBuffer to sys::fs::file_tReid Kleckner2019-07-101-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: On Windows, Posix integer file descriptors are a compatibility layer over native file handles provided by the C runtime. There is a hard limit on the maximum number of file descriptors that a process can open, and the limit is 8192. LLD typically doesn't run into this limit because it opens input files, maps them into memory, and then immediately closes the file descriptor. This prevents it from running out of FDs. For various reasons, I'd like to open handles to every input file and keep them open during linking. That requires migrating MemoryBuffer over to taking open native file handles instead of integer FDs. Reviewers: aganea, Bigcheese Reviewed By: aganea Subscribers: smeenai, silvas, mehdi_amini, hiraditya, steven_wu, dexonsmith, dang, llvm-commits, zturner Tags: #llvm Differential Revision: https://reviews.llvm.org/D63453 llvm-svn: 365588
* Try to appease the Windows build bots.Sean Fertile2019-07-091-4/+12
| | | | | | | Several of the conditonal operators commited in llvm-svn: 365524 fail to compile on the windows buildbots. Converting to an if and early return to try to fix. llvm-svn: 365535
* [Object][XCOFF] Add support for 64-bit file header and section header dumping.Sean Fertile2019-07-094-150/+258
| | | | | | | | | | | Adds a readobj dumper for 32-bit and 64-bit section header tables, and extend support for the file-header dumping to include 64-bit object files. Also refactors the binary file parsing to be done in a helper function in an attempt to cleanup error handeling. Differential Revision: https://reviews.llvm.org/D63843 llvm-svn: 365524
* [Object/ELF.h] - Improve error reporting.George Rimar2019-07-051-2/+7
| | | | | | | | | | | | | | | | | The errors coming from ELF.h are usually not very useful because they are uninformative. This patch is a first step to improve the situation. I tested this patch with a run of check-llvm and found that few messages are untested. In this patch, I did not add more tests but marked all such cases with a "TODO" comment. For all tested messages I extended the error text to provide more details (see test cases changed). Differential revision: https://reviews.llvm.org/D64014 llvm-svn: 365183
* [MachO] Add valid architecture functionShoaib Meenai2019-07-041-19/+10
| | | | | | | | | | | Added array of valid architectures and function returning array. Modified llvm-lipo to include list of valid architectures in error message for invalid arch. Patch by Anusha Basana <anusha.basana@gmail.com> Differential Revision: https://reviews.llvm.org/D63735 llvm-svn: 365099
* Share /machine: handling code with llvm-cvtres tooNico Weber2019-06-122-0/+45
| | | | | | | | | | | | | | r363016 let lld-link and llvm-lib share the /machine: parsing code. This lets llvm-cvtres share it as well. Making llvm-cvtres depend on llvm-lib seemed a bit strange (it doesn't need llvm-lib's dependencies on BinaryFormat and BitReader) and I couldn't find a good place to put this code. Since it's just a few lines, put it in lib/Object for now. Differential Revision: https://reviews.llvm.org/D63120 llvm-svn: 363144
* lld-link: Reject more than one resource .obj fileNico Weber2019-06-111-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Users are exepcted to pass all .res files to the linker, which then merges all the resource in all .res files into a tree structure and then converts the final tree structure to a .obj file with .rsrc$01 and .rsrc$02 sections and then links that. If the user instead passes several .obj files containing such resources, the correct thing to do would be to have custom code to merge the trees in the resource sections instead of doing normal section merging -- but link.exe rejects if multiple resource obj files are passed in with LNK4078, so let lld-link do that too instead of silently writing broken .rsrc sections in that case. The only real way to run into this is if users manually convert .res files to .obj files by running cvtres and then handing the resulting .obj files to lld-link instead, which in practice likely never happens. (lld-link is slightly stricter than link.exe now: If link.exe is passed one .obj file created by cvtres, and a .res file, for some reason it just emits a warning instead of an error and outputs strange looking data. lld-link now errors out on mixed input like this.) One way users could accidentally run into this is the following scenario: If a .res file is passed to lib.exe, then lib.exe calls cvtres.exe on the .res file before putting it in the output .lib. (llvm-lib currently doesn't do this.) link.exe's /wholearchive seems to only add obj files referenced from the static library index, but lld-link current really adds all files in the archive. So if lld-link /wholearchive is used with .lib files produced by lib.exe and .res files were among the files handed to lib.exe, we previously silently produced invalid output, but now we error out. link.exe's /wholearchive semantics on the other hand mean that it wouldn't load the resource object files from the .lib file at all. Since this scenario is probably still an unlikely corner case, the difference in behavior here seems fine -- and lld-link might have to change to use link.exe's /wholearchive semantics in the future anyways. Vaguely related to PR42180. Differential Revision: https://reviews.llvm.org/D63109 llvm-svn: 363078
* Let writeWindowsResourceCOFF() take a TimeStamp parameterNico Weber2019-06-111-15/+11
| | | | | | | | | | | | | | | | | | | For lld, pass in Config->Timestamp (which is set based on lld's /timestamp: and /Brepro flags). Since the writeWindowsResourceCOFF() data is only used in-memory by LLD and the obj's timestamp isn't used for anything in the output, this doesn't change behavior. For llvm-cvtres, add an optional /timestamp: parameter, and use the current behavior of calling time() if the parameter is not passed in. This doesn't really change observable behavior (unless someone passes /timestamp: to llvm-cvtres, which wasn't possible before), but it removes the last unqualified call to time() from llvm/lib, which seems like a good thing. Differential Revision: https://reviews.llvm.org/D63116 llvm-svn: 363050
* [MACHO] Replaced calls to getStruct with getStructOrErr in functions ↵Alex Brachet2019-06-041-33/+88
| | | | | | returning Error or Expected or similar llvm-svn: 362526
* [AArch64][ELF][llvm-readobj] Add support for BTI and PAC dynamic tagsPeter Smith2019-06-041-0/+10
| | | | | | | | | | | | | | | | | | | | | | | ELF for the 64-bit Arm Architecture defines two processor-specific dynamic tags: DT_AARCH64_BTI_PLT 0x70000001, d_val DT_AARCH64_PAC_PLT 0x70000003, d_val These presence of these tags indicate that PLT sequences have been protected using Branch Target Identification and Pointer Authentication respectively. The presence of both indicates that the PLT sequences have been protected with both Branch Target Identification and Pointer Authentication. This patch adds the tags and tests for llvm-readobj and yaml2obj. As some of the processor specific dynamic tags overlap, this patch splits them up, keeping their original default value if they were not previously mentioned explicitly in a switch case. Differential Revision: https://reviews.llvm.org/D62596 llvm-svn: 362493
* [llvm-ar] Reapply Fix relative thin archive path handlingOwen Reynolds2019-06-041-17/+34
| | | | | | | | | | Includes a fix for an introduced build failure due to a post c++11 use of std::mismatch. This fixes some thin archive relative path issues, paths are shortened where possible and paths are output correctly when using the display table command. Differential Revision: https://reviews.llvm.org/D59491 llvm-svn: 362484
* Revert "[llvm-ar] Fix relative thin archive path handling"Dmitri Gribenko2019-06-031-34/+17
| | | | | | | | | | This reverts commit r362407. It broke compilation of llvm/lib/Object/ArchiveWriter.cpp: error: type 'llvm::sys::path::const_iterator' does not provide a call operator llvm-svn: 362413
* [llvm-ar] Fix relative thin archive path handlingOwen Reynolds2019-06-031-17/+34
| | | | | | | | This fixes some thin archive relative path issues, paths are shortened where possible and paths are output correctly when using the display table command. Differential Revision: https://reviews.llvm.org/D59491 llvm-svn: 362407
* [ARM] add target arch definitions for 8.1-M and MVESjoerd Meijer2019-05-301-0/+18
| | | | | | | | | | | | | | | | | This adds: - LLVM subtarget features to make all the new instructions conditional on, - CPU and FPU names for use on clang's command line, with default FPUs set so that "armv8.1-m.main+fp" and "armv8.1-m.main+fp.dp" will select the right FPU features, - architecture extension names "mve" and "mve.fp", - ABI build attribute support for v8.1-M (a new value for Tag_CPU_arch) and MVE (a new actual tag). Patch mostly by Simon Tatham. Differential Revision: https://reviews.llvm.org/D60698 llvm-svn: 362090
* Add IR support, ELF section and user documentation for partitioning feature.Peter Collingbourne2019-05-291-0/+1
| | | | | | | | | | | | The partitioning feature was proposed here: http://lists.llvm.org/pipermail/llvm-dev/2019-February/130583.html This is mostly just documentation. The feature itself will be contributed in subsequent patches. Differential Revision: https://reviews.llvm.org/D60242 llvm-svn: 361923
* [ARM] Replace fp-only-sp and d16 with fp64 and d32.Simon Tatham2019-05-281-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Those two subtarget features were awkward because their semantics are reversed: each one indicates the _lack_ of support for something in the architecture, rather than the presence. As a consequence, you don't get the behavior you want if you combine two sets of feature bits. Each SubtargetFeature for an FP architecture version now comes in four versions, one for each combination of those options. So you can still say (for example) '+vfp2' in a feature string and it will mean what it's always meant, but there's a new string '+vfp2d16sp' meaning the version without those extra options. A lot of this change is just mechanically replacing positive checks for the old features with negative checks for the new ones. But one more interesting change is that I've rearranged getFPUFeatures() so that the main FPU feature is appended to the output list *before* rather than after the features derived from the Restriction field, so that -fp64 and -d32 can override defaults added by the main feature. Reviewers: dmgreen, samparker, SjoerdMeijer Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D60691 llvm-svn: 361845
* [XCOFF] Implement parsing symbol table for xcoffobjfile and output as yaml ↵Jason Liu2019-05-281-39/+163
| | | | | | | | | | | | | | | | | | | | | | | | | | | format Summary: This patch implement parsing symbol table for xcoffobjfile and output as yaml format. Parsing auxiliary entries of a symbol will be in a separate patch. The XCOFF object file (aix_xcoff.o) used in the test comes from -bash-4.2$ cat test.c extern int i; extern int TestforXcoff; int main() { i++; TestforXcoff--; } Patch by DiggerLin Reviewers: sfertile, hubert.reinterpretcast, MaskRay, daltenty Differential Revision: https://reviews.llvm.org/D61532 llvm-svn: 361832
* [LLVM-C] Add Accessor for Mach-O Universal Binary SlicesRobert Widmann2019-05-251-0/+15
| | | | | | | | | | | | | | | | Summary: Allow for retrieving an object file corresponding to an architecture-specific slice in a Mach-O universal binary file. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60378 llvm-svn: 361705
* [llvm-dlltool] Respect NONAME keywordMartin Storsjo2019-05-221-1/+4
| | | | | | | | | | | This adds proper handling of the NONAME-keyword, which makes llvm-dlltool generate an import using the ordinal instead of the name. Patch by by Jannik Vogel, test added by Stefan Schmidt. Differential Revision: https://reviews.llvm.org/D62175 llvm-svn: 361367
* [ELF] Implement Dependent Libraries FeatureBen Dunbobbin2019-05-172-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements a limited form of autolinking primarily designed to allow either the --dependent-library compiler option, or "comment lib" pragmas ( https://docs.microsoft.com/en-us/cpp/preprocessor/comment-c-cpp?view=vs-2017) in C/C++ e.g. #pragma comment(lib, "foo"), to cause an ELF linker to automatically add the specified library to the link when processing the input file generated by the compiler. Currently this extension is unique to LLVM and LLD. However, care has been taken to design this feature so that it could be supported by other ELF linkers. The design goals were to provide: - A simple linking model for developers to reason about. - The ability to to override autolinking from the linker command line. - Source code compatibility, where possible, with "comment lib" pragmas in other environments (MSVC in particular). Dependent library support is implemented differently for ELF platforms than on the other platforms. Primarily this difference is that on ELF we pass the dependent library specifiers directly to the linker without manipulating them. This is in contrast to other platforms where they are mapped to a specific linker option by the compiler. This difference is a result of the greater variety of ELF linkers and the fact that ELF linkers tend to handle libraries in a more complicated fashion than on other platforms. This forces us to defer handling the specifiers to the linker. In order to achieve a level of source code compatibility with other platforms we have restricted this feature to work with libraries that meet the following "reasonable" requirements: 1. There are no competing defined symbols in a given set of libraries, or if they exist, the program owner doesn't care which is linked to their program. 2. There may be circular dependencies between libraries. The binary representation is a mergeable string section (SHF_MERGE, SHF_STRINGS), called .deplibs, with custom type SHT_LLVM_DEPENDENT_LIBRARIES (0x6fff4c04). The compiler forms this section by concatenating the arguments of the "comment lib" pragmas and --dependent-library options in the order they are encountered. Partial (-r, -Ur) links are handled by concatenating .deplibs sections with the normal mergeable string section rules. As an example, #pragma comment(lib, "foo") would result in: .section ".deplibs","MS",@llvm_dependent_libraries,1 .asciz "foo" For LTO, equivalent information to the contents of a the .deplibs section can be retrieved by the LLD for bitcode input files. LLD processes the dependent library specifiers in the following way: 1. Dependent libraries which are found from the specifiers in .deplibs sections of relocatable object files are added when the linker decides to include that file (which could itself be in a library) in the link. Dependent libraries behave as if they were appended to the command line after all other options. As a consequence the set of dependent libraries are searched last to resolve symbols. 2. It is an error if a file cannot be found for a given specifier. 3. Any command line options in effect at the end of the command line parsing apply to the dependent libraries, e.g. --whole-archive. 4. The linker tries to add a library or relocatable object file from each of the strings in a .deplibs section by; first, handling the string as if it was specified on the command line; second, by looking for the string in each of the library search paths in turn; third, by looking for a lib<string>.a or lib<string>.so (depending on the current mode of the linker) in each of the library search paths. 5. A new command line option --no-dependent-libraries tells LLD to ignore the dependent libraries. Rationale for the above points: 1. Adding the dependent libraries last makes the process simple to understand from a developers perspective. All linkers are able to implement this scheme. 2. Error-ing for libraries that are not found seems like better behavior than failing the link during symbol resolution. 3. It seems useful for the user to be able to apply command line options which will affect all of the dependent libraries. There is a potential problem of surprise for developers, who might not realize that these options would apply to these "invisible" input files; however, despite the potential for surprise, this is easy for developers to reason about and gives developers the control that they may require. 4. This algorithm takes into account all of the different ways that ELF linkers find input files. The different search methods are tried by the linker in most obvious to least obvious order. 5. I considered adding finer grained control over which dependent libraries were ignored (e.g. MSVC has /nodefaultlib:<library>); however, I concluded that this is not necessary: if finer control is required developers can fall back to using the command line directly. RFC thread: http://lists.llvm.org/pipermail/llvm-dev/2019-March/131004.html. Differential Revision: https://reviews.llvm.org/D60274 llvm-svn: 360984
* Minidump: Add support for the MemoryList streamPavel Labath2019-05-161-0/+2
| | | | | | | | | | | | | | | | | | Summary: the stream format is exactly the same as for ThreadList and ModuleList streams, only the entry types are slightly different, so the changes in this patch are just straight-forward applications of established patterns. Reviewers: amccarth, jhenderson, clayborg Subscribers: markmentovai, lldb-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61885 llvm-svn: 360908
* Recommit [Object] Change object::SectionRef::getContents() to return ↵Fangrui Song2019-05-163-14/+15
| | | | | | | | | | | | 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
* Revert r360876 "[Object] Change object::SectionRef::getContents() to return ↵Hans Wennborg2019-05-163-15/+14
| | | | | | | | | | | | Expected<StringRef>" It broke the Clang build, see llvm-commits thread. > Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. > > Follow-up of D61781. llvm-svn: 360878
* [Object] Change object::SectionRef::getContents() to return Expected<StringRef>Fangrui Song2019-05-163-14/+15
| | | | | | | | Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. Follow-up of D61781. llvm-svn: 360876
* AArch64: support binutils-like things on arm64_32.Tim Northover2019-05-141-2/+20
| | | | | | | | This adds support for the arm64_32 watchOS ABI to LLVM's low level tools, teaching them about the specific MachO choices and constants needed to disassemble things. llvm-svn: 360663
* [Object] Change ObjectFile::getSectionContents to return ↵Fangrui Song2019-05-144-23/+18
| | | | | | | | | | | | | | | | | | | Expected<ArrayRef<uint8_t>> Change std::error_code getSectionContents(DataRefImpl, StringRef &) const; to Expected<ArrayRef<uint8_t>> getSectionContents(DataRefImpl) const; Many object formats use ArrayRef<uint8_t> as the underlying type, which is generally better than StringRef to represent binary data, so change the type to decrease the number of type conversions. Reviewed By: ruiu, sbc100 Differential Revision: https://reviews.llvm.org/D61781 llvm-svn: 360648
* [Object] Move ELF specific ObjectFile::getBuildAttributes to ELFObjectFileBaseFangrui Song2019-05-101-4/+2
| | | | | | | Change the return type from std::error_code to Error and make the function protected. llvm-svn: 360416
OpenPOWER on IntegriCloud