maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/tools/llvm-lto/error.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

15 lines
1000 B
LLVM
Raw Normal View History

Add a missing error handling to llvm-lto. llvm-svn: 257395
2016-01-12 06:08:22 +08:00
; RUN: not llvm-lto foobar 2>&1 | FileCheck %s
Fix test on windows. llvm-svn: 257475
2016-01-12 22:58:40 +08:00
; CHECK: llvm-lto: error loading file 'foobar': {{N|n}}o such file or directory
[LTO] Fix error reporting from lto_module_create_in_local_context() Function lto_module_create_in_local_context() would previously rely on the default LLVMContext being created for it by LTOModule::makeLTOModule(). This context exits the program on error and is not arranged to update sLastStringError in tools/lto/lto.cpp. Function lto_module_create_in_local_context() now creates an LLVMContext by itself, sets it up correctly to its needs and then passes it to LTOModule::createInLocalContext() which takes ownership of the context and keeps it present for the lifetime of the returned LTOModule. Function LTOModule::makeLTOModule() is modified to take a reference to LLVMContext (instead of a pointer) and no longer creates a default context when nullptr is passed to it. Method LTOModule::createInContext() that takes a pointer to LLVMContext is removed because it allows to pass a nullptr to it. Instead LTOModule::createFromBuffer() (that takes a reference to LLVMContext) should be used. Differential Revision: http://reviews.llvm.org/D17715 llvm-svn: 262330
2016-03-01 21:13:49 +08:00
; RUN: not llvm-lto --list-symbols-only %S/Inputs/empty.bc 2>&1 | FileCheck %s --check-prefix=CHECK-LIST
; CHECK-LIST: llvm-lto: error loading file '{{.*}}/Inputs/empty.bc': The file was not recognized as a valid object file
Add a test for r263577: "Add missing error handling in llvm-lto" On Rafael's suggestion! (also fix a discrepancy between this error message format and the others) From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 263860
2016-03-19 08:17:32 +08:00
[ThinLTO]LTO]Legacy] Fix dependent libraries support by adding querying of the IRSymtab Dependent libraries support for the legacy api was committed in a broken state (see: https://reviews.llvm.org/D60274). This was missed due to the painful nature of having to integrate the changes into a linker in order to test. This change implements support for dependent libraries in the legacy LTO api: - I have removed the current api function, which returns a single string, and added functions to access each dependent library specifier individually. - To reduce the testing pain, I have made the api functions as thin as possible to maximize coverage from llvm-lto. - When doing ThinLTO the system linker will load the modules lazily when scanning the input files. Unfortunately, when modules are lazily loaded there is no access to module level named metadata. To fix this I have added api functions that allow querying the IRSymtab for the dependent libraries. I hope to expand the api in the future so that, eventually, all the information needed by a client linker during scan can be retrieved from the IRSymtab. Differential Revision: https://reviews.llvm.org/D62935 llvm-svn: 363140
2019-06-12 19:07:56 +08:00
; RUN: not llvm-lto --list-dependent-libraries-only %S/Inputs/empty.bc 2>&1 | FileCheck %s --check-prefix=CHECK-LIBS
; CHECK-LIBS: llvm-lto: {{.*}}/Inputs/empty.bc: Could not read LTO input file: The file was not recognized as a valid object file
[LTO][Legacy] Add new API to query Mach-O CPU (sub)type Tools working with object files on Darwin (e.g. lipo) may need to know properties like the CPU type and subtype of a bitcode file. The logic of converting a triple to a Mach-O CPU_(SUB_)TYPE should be provided by LLVM instead of relying on tools to re-implement it. Differential Revision: https://reviews.llvm.org/D75067
2020-02-19 09:13:47 +08:00
; RUN: not llvm-lto --print-macho-cpu-only %S/Inputs/empty.bc 2>&1 | FileCheck %s --check-prefix=CHECK-MACHO
; CHECK-MACHO: llvm-lto: error: The file was not recognized as a valid object file
Add a test for r263577: "Add missing error handling in llvm-lto" On Rafael's suggestion! (also fix a discrepancy between this error message format and the others) From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 263860
2016-03-19 08:17:32 +08:00
; RUN: not llvm-lto --thinlto %S/Inputs/empty.bc 2>&1 | FileCheck %s --check-prefix=CHECK-THIN
BitStream reader: propagate errors The bitstream reader handles errors poorly. This has two effects: * Bugs in file handling (especially modules) manifest as an "unexpected end of file" crash * Users of clang as a library end up aborting because the code unconditionally calls `report_fatal_error` The bitstream reader should be more resilient and return Expected / Error as soon as an error is encountered, not way late like it does now. This patch starts doing so and adopting the error handling where I think it makes sense. There's plenty more to do: this patch propagates errors to be minimally useful, and follow-ups will propagate them further and improve diagnostics. https://bugs.llvm.org/show_bug.cgi?id=42311 <rdar://problem/33159405> Differential Revision: https://reviews.llvm.org/D63518 llvm-svn: 364464
2019-06-27 03:50:12 +08:00
; CHECK-THIN: llvm-lto: error loading file '{{.*}}/Inputs/empty.bc': file too small to contain bitcode header