aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Object
AgeCommit message (Collapse)AuthorFilesLines
2019-08-28[llvm-objdump] Add the missing ARMv8 subarch detectionYi Kong1-0/+15
Differential Revision: https://reviews.llvm.org/D66849 llvm-svn: 370163
2019-08-27[XCOFF][AIX] Generate symbol table entries with llvm-readobjJason Liu1-20/+143
Summary: This patch implements main entry and auxiliary entries of symbol table generation for llvm-readobj on AIX. The source code of aix_xcoff_xlc_test8.o (compile with xlc) is: -bash-4.2$ cat test8.c extern int i; extern int TestforXcoff; extern int fun(int i); static int static_i; char* p="abcd"; int fun1(int j) { static_i++; j++; j=j+*p; return j; } int main() { i++; fun(i); return fun1(i); } Patch provided by DiggerLin Differential Revision: https://reviews.llvm.org/D65240 llvm-svn: 370097
2019-08-21[Object] FIX: update PlatformKind name in TapiFileCyndy Ishida1-2/+2
Buildbots that use GCC failed to compile because overwritten namespace with variable name llvm-svn: 369602
2019-08-21[Object] Add tapi files to objectCyndy Ishida5-3/+163
Summary: The intention for this is to allow reading and printing symbols out from llvm-nm. Tapi file, and Tapi universal follow a similiar format to their respective MachO Object format. The tests are dependent on llvm-nm processing tbd files which is why its in D66160 Reviewers: ributzka, steven_wu, lhames Reviewed By: ributzka, lhames Subscribers: mgorny, hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66159 llvm-svn: 369600
2019-08-21[BinaryFormat] Teach identify_magic about Tapi files.Cyndy Ishida3-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
2019-08-21Be explicit about Windows coff name trailing character policySerge Guelton1-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
2019-08-20[yaml2obj/obj2yaml][MachO] Allow setting custom section dataSeiya Nuta1-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
2019-08-19[Object/COFF.h] - Stop returning std::error_code in a few methods. NFCI.George Rimar1-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
2019-08-17[BPF] Fix bpf llvm-objdump issues.Yonghong Song1-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
2019-08-15[llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere4-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
2019-08-14Recommit r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar5-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
2019-08-14Revert r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar5-33/+20
Expected<>" It broke clang BB: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/16455 llvm-svn: 368813
2019-08-14[llvm/Object] - Convert SectionRef::getName() to return Expected<>George Rimar5-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
2019-08-12[XCOFF] Use a single symbolic constant for the size of an embeded name. [NFC]Sean Fertile1-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
2019-08-09Print reasonable representations of type names in llvm-nm, readelf and readobjSunil Srivastava1-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
2019-08-06Switch LLVM to use 64-bit offsets (2/5)Igor Kudrin2-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
2019-08-02[NFC] Test commit, corrected some spelling in commentDavid Candler1-1/+1
Test commit, corrected some spelling in comment. Differential Revision: https://reviews.llvm.org/D65516 llvm-svn: 367685
2019-07-25[Object] Add public MaxSectionAlignment to MachOUniversalShoaib Meenai1-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
2019-07-23[llvm-ar] Fix support for archives with members larger than 4GBOwen Reynolds2-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
2019-07-22[Object][XCOFF] Remove extra includes from XCOFF related files. [NFC]Sean Fertile1-5/+0
Differential Revision: https://reviews.llvm.org/D60885 llvm-svn: 366723
2019-07-19[DebugInfo] Generate fixups as emitting DWARF .debug_frame/.eh_frame.Hsiangkai Wang1-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
2019-07-18Remove the static initialize introduced in r365099Steven Wu1-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
2019-07-18Revert "[DebugInfo] Generate fixups as emitting DWARF .debug_frame/.eh_frame."Hsiangkai Wang1-6/+0
This reverts commit 17e3cbf5fe656483d9016d0ba9e1d0cd8629379e. llvm-svn: 366444
2019-07-18[DebugInfo] Generate fixups as emitting DWARF .debug_frame/.eh_frame.Hsiangkai Wang1-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
2019-07-18[DWARF][RISCV] Add support for RISC-V relocations needed for debug infoAlex Bradbury1-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
2019-07-13[Object] isNotObjectErrorInvalidFileType: simplifyFangrui Song1-13/+10
llvm-svn: 365997
2019-07-13[Object] isNotObjectErrorInvalidFileType: fix use-after-moveFangrui Song1-1/+1
llvm-svn: 365996
2019-07-10[Support] Move llvm::MemoryBuffer to sys::fs::file_tReid Kleckner1-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
2019-07-09Try to appease the Windows build bots.Sean Fertile1-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
2019-07-09[Object][XCOFF] Add support for 64-bit file header and section header dumping.Sean Fertile4-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
2019-07-05[Object/ELF.h] - Improve error reporting.George Rimar1-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
2019-07-04[MachO] Add valid architecture functionShoaib Meenai1-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
2019-06-12Share /machine: handling code with llvm-cvtres tooNico Weber2-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
2019-06-11lld-link: Reject more than one resource .obj fileNico Weber1-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
2019-06-11Let writeWindowsResourceCOFF() take a TimeStamp parameterNico Weber1-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
2019-06-04[MACHO] Replaced calls to getStruct with getStructOrErr in functions ↵Alex Brachet1-33/+88
returning Error or Expected or similar llvm-svn: 362526
2019-06-04[AArch64][ELF][llvm-readobj] Add support for BTI and PAC dynamic tagsPeter Smith1-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
2019-06-04[llvm-ar] Reapply Fix relative thin archive path handlingOwen Reynolds1-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
2019-06-03Revert "[llvm-ar] Fix relative thin archive path handling"Dmitri Gribenko1-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
2019-06-03[llvm-ar] Fix relative thin archive path handlingOwen Reynolds1-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
2019-05-30[ARM] add target arch definitions for 8.1-M and MVESjoerd Meijer1-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
2019-05-29Add IR support, ELF section and user documentation for partitioning feature.Peter Collingbourne1-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
2019-05-28[ARM] Replace fp-only-sp and d16 with fp64 and d32.Simon Tatham1-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
2019-05-28[XCOFF] Implement parsing symbol table for xcoffobjfile and output as yaml ↵Jason Liu1-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
2019-05-25[LLVM-C] Add Accessor for Mach-O Universal Binary SlicesRobert Widmann1-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
2019-05-22[llvm-dlltool] Respect NONAME keywordMartin Storsjo1-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
2019-05-17[ELF] Implement Dependent Libraries FeatureBen Dunbobbin2-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
2019-05-16Minidump: Add support for the MemoryList streamPavel Labath1-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
2019-05-16Recommit [Object] Change object::SectionRef::getContents() to return ↵Fangrui Song3-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
2019-05-16Revert r360876 "[Object] Change object::SectionRef::getContents() to return ↵Hans Wennborg3-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
generated by cgit v1.1 at 2025-10-08 19:21:08 +0000