summaryrefslogtreecommitdiffstats
path: root/llvm/test/Object
Commit message (Collapse)AuthorAgeFilesLines
* Start to add real error messages for malformed Mach-O files.Kevin Enderby2016-04-131-12/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | And update the existing test cases in test/Object/macho-invalid.test to use llvm-objdump with the -macho option to produce these error messages and stop producing the generic "Invalid data was encountered while parsing the file" message. Working from the beginning of the file, if the mach header is too large for the size of the file and then if the load commands that follow extend past the end of the file these two errors now generate correct error messages. Both of these have existing test cases in test/Object/macho-invalid.test . But the first with macho-invalid-header it will never trigger the error message "mach header extends past the end of the file" using any of the llvm tools as they all use identify_magic() which rejects files with the correct magic number that are too small in size. So I tested this by hacking that code and seeing the error message down in parseHeader() really does happen. So in case there is ever code in llvm that directly calls createMachOObjectFile() this error message will be correctly produced. The second error message of "load commands extends past the end of the file" is triggered by a number of existing tests cases in test/Object/macho-invalid.test . Also other tests trigger different error messages now like "ilocalsym plus nlocalsym in LC_DYSYMTAB load command extends past the end of the symbol table". There are two existing test cases that still get the "Invalid data was encountered ..." error messages that I will tackle next. But they will involve a bit of pluming an Expect<...> up through the call stack and I want to do those as separate changes. FYI, for those test cases that were trying to test specific errors that now get different errors I’ll fix those in follow on changes and create new test cases for those so they test the error they were meant to test. llvm-svn: 266248
* Revert r265817Colin LeMahieu2016-04-084-12/+12
| | | | | | lld tests need to be addressed. llvm-svn: 265822
* [llvm-objdump] Printing hex instead of dec by defaultColin LeMahieu2016-04-084-12/+12
| | | | | | Differential Revision: http://reviews.llvm.org/D18770 llvm-svn: 265817
* [AMDGPU] llvm-objdump: Minimal HSA Code Object disassembler support.Valery Pykhtin2016-04-072-0/+77
| | | | | | | | | | | | Reenable reverted r265550 with endianness issue fixed. Variables of endian-aware types such as ulittle32_t should be explicitly casted to their natural equivalent types before passing it as vararg to printf like functions (format in my case). Added lit config file depending on AMDGPU target as the testcase uses assembler. Differential revision: http://reviews.llvm.org/D16998 llvm-svn: 265645
* Thread Expected<...> up from createMachOObjectFile() to allow llvm-objdump ↵Kevin Enderby2016-04-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to produce a real error message Produce the first specific error message for a malformed Mach-O file describing the problem instead of the generic message for object_error::parse_failed of "Invalid data was encountered while parsing the file”.  Many more good error messages will follow after this first one. This is built on Lang Hames’ great work of adding the ’Error' class for structured error handling and threading Error through MachOObjectFile construction. And making createMachOObjectFile return Expected<...> . So to to get the error to the llvm-obdump tool, I changed the stack of these methods to also return Expected<...> : object::ObjectFile::createObjectFile() object::SymbolicFile::createSymbolicFile() object::createBinary() Then finally in ParseInputMachO() in MachODump.cpp the error can be reported and the specific error message can be printed in llvm-objdump and can be seen in the existing test case for the existing malformed binary but with the updated error message. Converting these interfaces to Expected<> from ErrorOr<> does involve touching a number of places. To contain the changes for now use of errorToErrorCode() and errorOrToExpected() are used where the callers are yet to be converted. Also there some were bugs in the existing code that did not deal with the old ErrorOr<> return values. So now with Expected<> since they must be checked and the error handled, I added a TODO and a comment: “// TODO: Actually report errors helpfully” and a call something like consumeError(ObjOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. Note there is one fix also needed to lld/COFF/InputFiles.cpp that goes along with this that I will commit right after this. So expect lld not to built after this commit and before the next one. llvm-svn: 265606
* Revert "[AMDGPU] llvm-objdump: Minimal HSA Code Object disassembler support."Valery Pykhtin2016-04-061-75/+0
| | | | | | This reverts commit r265550. There're problems with endianness on dumping instruction bytes. Need to find out how to use support::ulittle32_t type properly. llvm-svn: 265554
* [AMDGPU] llvm-objdump: Minimal HSA Code Object disassembler support.Valery Pykhtin2016-04-061-0/+75
| | | | | | Differential revision: http://reviews.llvm.org/D16998 llvm-svn: 265550
* Create thin archive in GNU format to fix test on OS X.Peter Collingbourne2016-03-311-1/+2
| | | | llvm-svn: 265069
* Object: Correctly read thin archives containing absolute paths.Peter Collingbourne2016-03-311-0/+5
| | | | | | Differential Revision: http://reviews.llvm.org/D18666 llvm-svn: 265065
* [lanai] Add Lanai backend.Jacques Pienaar2016-03-281-1/+1
| | | | | | | | | | Add the Lanai backend to lib/Target. General Lanai backend discussion on llvm-dev thread "[RFC] Lanai backend" (http://lists.llvm.org/pipermail/llvm-dev/2016-February/095118.html). Differential Revision: http://reviews.llvm.org/D17011 llvm-svn: 264578
* [llvm-readobj] Decode st_other symbol's flagsSimon Atanasyan2016-03-241-3/+11
| | | | | | | | | The patch supports common STV_xxx visibility flags and MIPS specific STO_MIPS_xxx flags. Differential Revision: http://reviews.llvm.org/D18447 llvm-svn: 264300
* Fix a crash in running llvm-objdump -t with an invalid Mach-O file alreadyKevin Enderby2016-03-231-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in the test suite. While this is not really an interesting tool and option to run on a Mach-O file to show the symbol table in a generic libObject format it shouldn’t crash. The reason for the crash was in MachOObjectFile::getSymbolType() when it was calling MachOObjectFile::getSymbolSection() without checking its return value for the error case. What makes this fix require a fair bit of diffs is that the method getSymbolType() is in the class ObjectFile defined without an ErrorOr<> so I needed to add that all the sub classes.  And all of the uses needed to be updated and the return value needed to be checked for the error case. The MachOObjectFile version of getSymbolType() “can” get an error in trying to come up with the libObject’s internal SymbolRef::Type when the Mach-O symbol symbol type is an N_SECT type because the code is trying to select from the SymbolRef::ST_Data or SymbolRef::ST_Function values for the SymbolRef::Type. And it needs the Mach-O section to use isData() and isBSS to determine if it will return SymbolRef::ST_Data. One other possible fix I considered is to simply return SymbolRef::ST_Other when MachOObjectFile::getSymbolSection() returned an error. But since in the past when I did such changes that “ate an error in the libObject code” I was asked instead to push the error out of the libObject code I chose not to implement the fix this way. As currently written both the COFF and ELF versions of getSymbolType() can’t get an error. But if isReservedSectionNumber() wanted to check for the two known negative values rather than allowing all negative values or the code wanted to add the same check as in getSymbolAddress() to use getSection() and check for the error then these versions of getSymbolType() could return errors. At the end of the day the error printed now is the generic “Invalid data was encountered while parsing the file” for object_error::parse_failed. In the future when we thread Lang’s new TypedError for recoverable error handling though libObject this will improve. And where the added // Diagnostic(… comment is, it would be changed to produce and error message like “bad section index (42) for symbol at index 8” for this case. llvm-svn: 264187
* Add a testcase that would have found the bug in r263971.Rafael Espindola2016-03-212-0/+12
| | | | llvm-svn: 263988
* Revert "[llvm-objdump] Printing relocations in executable and shared object ↵Rafael Espindola2016-03-211-0/+5
| | | | | | | | | files. This partially reverts r215844 by removing test objdump-reloc-shared.test which stated GNU objdump doesn't print relocations, it does." This reverts commit r263971. It produces the wrong results for .rela.dyn. I will add a test. llvm-svn: 263987
* [llvm-objdump] Printing relocations in executable and shared object files. ↵Colin LeMahieu2016-03-211-5/+0
| | | | | | | | | | This partially reverts r215844 by removing test objdump-reloc-shared.test which stated GNU objdump doesn't print relocations, it does. In executable and shared object ELF files, relocations in the file contain the final virtual address rather than section offset so this is adjusted to display section offset. Differential revision: http://reviews.llvm.org/D15965 llvm-svn: 263971
* [yaml2obj, COFF] Correctly handle section alignmentDavid Majnemer2016-03-171-0/+14
| | | | | | | | | The section alignment field was marked optional but not provided a default value: initialize it with 0. While we are here, ensure that the section alignment is plausible. llvm-svn: 263692
* [AMDGPU] add AMDGPU target support to ELFObjectFile.h headerValery Pykhtin2016-03-093-0/+25
| | | | | | Differential Revision: http://reviews.llvm.org/D17144 llvm-svn: 263026
* [lanai] Add ELF enum value and relocations.Jacques Pienaar2016-03-012-0/+68
| | | | | | | | | | Add ELF enum value and relocations for Lanai backed. General Lanai backend discussion on llvm-dev thread "[RFC] Lanai backend" (http://lists.llvm.org/pipermail/llvm-dev/2016-February/095118.html). Differential Revision: http://reviews.llvm.org/D17008 llvm-svn: 262394
* IRObject: Mark extern_weak as weak.Rafael Espindola2016-02-291-0/+4
| | | | llvm-svn: 262222
* Represent the dynamic table itself with a DynRegionInfo.Rafael Espindola2016-02-171-1/+1
| | | | | | | | | | | | The dynamic table is also an array of a fixed structure, so it can be represented with a DynReginoInfo. No major functionality change. The extra error checking is covered by existing tests with a broken dynamic program header. Idea extracted from r260488. I did the extra cleanups. llvm-svn: 261107
* Change how readobj stores info about dynamic symbols.Rafael Espindola2016-02-172-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We used to keep both a section and a pointer to the first symbol. The oddity of keeping a section for dynamic symbols is because there is a DT_SYMTAB but no DT_SYMTABZ, so to print the table we have to find the size via a section table. The reason for still keeping a pointer to the first symbol is because we want to be able to print relocation tables even if the section table is missing (it is mandatory only for files used in linking). With this patch we keep just a DynRegionInfo. This then requires changing a few places that were asking for a Elf_Shdr but actually just needed the first symbol. The test change is to delete the program header pointer. Now that we use the information of both DT_SYMTAB and .dynsym, we don't depend on the sh_entsize of .dynsym if we see DT_SYMTAB. Note: It is questionable if it is worth it putting the effort to report broken sh_entsize given that in files with no section table we have to assume it is sizeof(Elf_Sym), but that is for another change. Extracted from r260488. llvm-svn: 261099
* Reapply r260489.Rafael Espindola2016-02-161-0/+12
| | | | | | | | | | Original commit message: [readobj] Dump DT_JMPREL relocations when outputting dynamic relocations. The bits of r260488 it depends on have been committed. llvm-svn: 260970
* Introduce a getAsRange helper.Rafael Espindola2016-02-161-1/+1
| | | | | | | | | This requires making an error message a bit more generic, but that seems a reasonable tradeoff. Extracted from r260488 but simplified a bit. llvm-svn: 260967
* This reverts commit r260488 and r260489.Rafael Espindola2016-02-164-17/+10
| | | | | | | | | | | Original messages: Revert "[readobj] Handle ELF files with no section table or with no program headers." Revert "[readobj] Dump DT_JMPREL relocations when outputting dynamic relocations." r260489 depends on r260488 and among other issues r260488 deleted error handling code. llvm-svn: 260962
* [readobj] Dump DT_JMPREL relocations when outputting dynamic relocations.Michael J. Spencer2016-02-111-0/+12
| | | | llvm-svn: 260489
* [readobj] Handle ELF files with no section table or with no program headers.Michael J. Spencer2016-02-113-10/+5
| | | | | | | | This adds support for finding the dynamic table and dynamic symbol table via the section table or the program header table. If there's no section table an attempt is made to figure out the length of the dynamic symbol table. llvm-svn: 260488
* Fix identify_magic() to check that a file that starts with MH_MAGIC isKevin Enderby2016-01-261-1/+2
| | | | | | | | | | | | at least as big as the mach header to be identified as a Mach-O file and make sure smaller files are not identified as a Mach-O files but as unknown files. Also fix identify_magic() so it looks at all 4 bytes of the filetype field when determining the type of the Mach-O file. Then fix the macho-invalid-header test case to check that it is an unknown file and make sure it does not get the error for object_error::parse_failed. And also update the unit tests. llvm-svn: 258883
* Update the comments for the macho-invalid-zero-ncmds test and fixKevin Enderby2016-01-261-2/+6
| | | | | | | | llvm-objdump when printing the Mach Header to print the unknown cputype and cpusubtype fields as decimal instead of not printing them at all. And change the test to check for that. llvm-svn: 258826
* Fix the code that leads to the incorrect trigger of the report_fatal_error()Kevin Enderby2016-01-222-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in MachOObjectFile::getSymbolByIndex() when a Mach-O file has a symbol table load command but the number of symbols are zero. The code in MachOObjectFile::symbol_begin_impl() should not be assuming there is a symbol at index 0, in cases there is no symbol table load command or the count of symbol is zero. So I also fixed that. And needed to fix MachOObjectFile::symbol_end_impl() to also do the same thing for no symbol table or one with zero entries. The code in MachOObjectFile::getSymbolByIndex() should trigger the report_fatal_error() for programmatic errors for any index when there is no symbol table load command and not return the end iterator. So also fixed that. Note there is no test case as this is a programmatic error. The test case using the file macho-invalid-bad-symbol-index has a symbol table load command with its number of symbols (nsyms) is zero. Which was incorrectly testing the bad triggering of the report_fatal_error() in in MachOObjectFile::getSymbolByIndex(). This test case is an invalid Mach-O file but not for that reason. It appears this Mach-O file use to have an nsyms value of 11, and what makes this Mach-O file invalid is the counts and indexes into the symbol table of the dynamic load command are now invalid because the number of symbol table entries (nsyms) is now zero. Which can be seen with the existing llvm-obdump: % llvm-objdump -private-headers macho-invalid-bad-symbol-index … Load command 4 cmd LC_SYMTAB cmdsize 24 symoff 4216 nsyms 0 stroff 4392 strsize 144 Load command 5 cmd LC_DYSYMTAB cmdsize 80 ilocalsym 0 nlocalsym 8 (past the end of the symbol table) iextdefsym 8 (greater than the number of symbols) nextdefsym 2 (past the end of the symbol table) iundefsym 10 (greater than the number of symbols) nundefsym 1 (past the end of the symbol table) ... And the native darwin tools generates an error for this file: % nm macho-invalid-bad-symbol-index nm: object: macho-invalid-bad-symbol-index truncated or malformed object (ilocalsym plus nlocalsym in LC_DYSYMTAB load command extends past the end of the symbol table) I added new checks for the indexes and sizes for these in the constructor of MachOObjectFile. And added comments for what would be a proper diagnostic messages. And changed the test case using macho-invalid-bad-symbol-index to test for the new error now produced. Also added a test with a valid Mach-O file with a symbol table load command where the number of symbols is zero that shows the report_fatal_error() is not called. llvm-svn: 258576
* Fix MachOObjectFile::getSymbolName() to not call report_fatal_error()Kevin Enderby2016-01-221-1/+7
| | | | | | | | | | | but to return object_error::parse_failed.  Then made the code in llvm-nm do for Mach-O files what is done in the darwin native tools which is to print "bad string index" for bad string indexes. Updated the error message in the llvm-objdump test, and added tests to show llvm-nm prints "bad string index" and a test to print the actual bad string index value which in this case is 0xfe000002 when printing the fields as raw hex. llvm-svn: 258520
* Fix MachOObjectFile::getSymbolSection() to not call report_fatal_error()Kevin Enderby2016-01-211-2/+8
| | | | | | | | | but to return object_error::parse_failed.  Then made the code in llvm-nm do for Mach-O files what is done in the darwin native tools which is to print "(?,?)" or just "s" for bad section indexes. Also added a test to show it prints the bad section index of "42" when printing the fields as raw hex. llvm-svn: 258434
* [llvm-readobj][ELF] Teach llvm-readobj to show arch specific ELF section's flagsSimon Atanasyan2016-01-201-1/+1
| | | | | | | | | | | | | | Some architecture specific ELF section flags might have the same value (for example SHF_X86_64_LARGE and SHF_HEX_GPREL) and we have to check machine architectures to select an appropriate set of possible flags. The patch selects architecture specific flags into separate arrays `ElfxxxSectionFlags` and combines `ElfSectionFlags` and `ElfxxxSectionFlags` before pass to the `StreamWriter::printFlags()` method. Differential Revision: http://reviews.llvm.org/D16269 llvm-svn: 258334
* [llvm-readobj][ELF] Teach llvm-readobj to show dynamic relocation in REL formatSimon Atanasyan2016-01-162-0/+71
| | | | | | | | | | MIPS 32-bit ABI uses REL relocation record format to save dynamic relocations. The patch teaches llvm-readobj to show dynamic relocations in this format. Differential Revision: http://reviews.llvm.org/D16114 llvm-svn: 258001
* [llvm-readobj] Dump DT_RELACOUNT correctly.Davide Italiano2016-01-161-1/+1
| | | | llvm-svn: 257988
* Handle archives with paths in the names.Rafael Espindola2015-12-182-0/+9
| | | | | | | | | | | | | | | | We always create archives with just he filename as the member name, but other archives can put a more complicated path in there. This patches handles it by computing just the filename as we do when adding a new member. If storing the path is important for some reason, we should probably have an orthogonal option for doing that and do it for both old and new members. Fixes pr25877. llvm-svn: 256001
* Stabilize llvm/test/Object/archive-update.test a bit.NAKAMURA Takumi2015-12-071-1/+2
| | | | | | | | A manipulation (in this case, mkdir) can make slack between creating and touching %t.older/evenlen. I would make this rewrote with python if this were still unstable. llvm-svn: 254965
* Revert "Change memcpy/memset/memmove to have dest and source alignments."Pete Cooper2015-11-191-2/+2
| | | | | | | | | | This reverts commit r253511. This likely broke the bots in http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/20202 http://bb.pgr.jp/builders/clang-3stage-i686-linux/builds/3787 llvm-svn: 253543
* Change memcpy/memset/memmove to have dest and source alignments.Pete Cooper2015-11-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note, this was reviewed (and more details are in) http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html These intrinsics currently have an explicit alignment argument which is required to be a constant integer. It represents the alignment of the source and dest, and so must be the minimum of those. This change allows source and dest to each have their own alignments by using the alignment attribute on their arguments. The alignment argument itself is removed. There are a few places in the code for which the code needs to be checked by an expert as to whether using only src/dest alignment is safe. For those places, they currently take the minimum of src/dest alignments which matches the current behaviour. For example, code which used to read: call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 500, i32 8, i1 false) will now read: call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 8 %dest, i8* align 8 %src, i32 500, i1 false) For out of tree owners, I was able to strip alignment from calls using sed by replacing: (call.*llvm\.memset.*)i32\ [0-9]*\,\ i1 false\) with: $1i1 false) and similarly for memmove and memcpy. I then added back in alignment to test cases which needed it. A similar commit will be made to clang which actually has many differences in alignment as now IRBuilder can generate different source/dest alignments on calls. In IRBuilder itself, a new argument was added. Instead of calling: CreateMemCpy(Dst, Src, getInt64(Size), DstAlign, /* isVolatile */ false) you now call CreateMemCpy(Dst, Src, getInt64(Size), DstAlign, SrcAlign, /* isVolatile */ false) There is a temporary class (IntegerAlignment) which takes the source alignment and rejects implicit conversion from bool. This is to prevent isVolatile here from passing its default parameter to the source alignment. Note, changes in future can now be made to codegen. I didn't change anything here, but this change should enable better memcpy code sequences. Reviewed by Hal Finkel. llvm-svn: 253511
* ELFYAML: Add support for parsing AMDGPU section attribute flagsTom Stellard2015-11-131-1/+16
| | | | | | | | | | Reviewers: silvas Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14444 llvm-svn: 253052
* Tests: be slightly more specific to avoid conflict with path.Tim Northover2015-10-261-1/+1
| | | | llvm-svn: 251290
* [AVR] Add ELF constants to headersDylan McKay2015-10-232-0/+62
| | | | | | | | Also adds a 'trivial' ELF file. This was generated by assembling and linking a file with the symbol main which contains a single return instruction. llvm-svn: 251096
* Fix printing of 64 bit values and make test more strict.Rafael Espindola2015-10-011-12/+26
| | | | llvm-svn: 249043
* Avoid SEGFAULT if a requested symbol section is absent.Rafael Espindola2015-09-211-0/+2
| | | | | | Patch by Igor Kudrin! llvm-svn: 248194
* Fixup r248096, commit the *correct* test.Davide Italiano2015-09-191-2/+2
| | | | llvm-svn: 248097
* [obj2yaml] Fix "time of check to time of use" bug. Add a test.Davide Italiano2015-09-191-0/+3
| | | | llvm-svn: 248096
* [opaque pointer type] Add textual IR support for explicit type parameter for ↵David Blaikie2015-09-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | global aliases update.py: import fileinput import sys import re alias_match_prefix = r"(.*(?:=|:|^)\s*(?:external |)(?:(?:private|internal|linkonce|linkonce_odr|weak|weak_odr|common|appending|extern_weak|available_externally) )?(?:default |hidden |protected )?(?:dllimport |dllexport )?(?:unnamed_addr |)(?:thread_local(?:\([a-z]*\))? )?alias" plain = re.compile(alias_match_prefix + r" (.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|addrspacecast|\[\[[a-zA-Z]|\{\{).*$)") cast = re.compile(alias_match_prefix + r") ((?:bitcast|inttoptr|addrspacecast)\s*\(.* to (.*?)(| addrspace\(\d+\) *)\*\)\s*(?:;.*)?$)") gep = re.compile(alias_match_prefix + r") ((?:getelementptr)\s*(?:inbounds)?\s*\((?P<type>.*), (?P=type)(?:\s*addrspace\(\d+\)\s*)?\* .*\)\s*(?:;.*)?$)") def conv(line): m = re.match(cast, line) if m: return m.group(1) + " " + m.group(3) + ", " + m.group(2) m = re.match(gep, line) if m: return m.group(1) + " " + m.group(3) + ", " + m.group(2) m = re.match(plain, line) if m: return m.group(1) + ", " + m.group(2) + m.group(3) + "*" + m.group(4) + "\n" return line for line in sys.stdin: sys.stdout.write(conv(line)) apply.sh: for name in "$@" do python3 `dirname "$0"`/update.py < "$name" > "$name.tmp" && mv "$name.tmp" "$name" rm -f "$name.tmp" done The actual commands: From llvm/src: find test/ -name *.ll | xargs ./apply.sh From llvm/src/tools/clang: find test/ -name *.mm -o -name *.m -o -name *.cpp -o -name *.c | xargs -I '{}' ../../apply.sh "{}" From llvm/src/tools/polly: find test/ -name *.ll | xargs ./apply.sh llvm-svn: 247378
* Object: Fix COFF import file's symbols.Rui Ueyama2015-09-011-3/+3
| | | | | | | If a symbol is marked as "data", the symbol should be exported with __imp_ prefix. Previously, the symbol was exported as-is. llvm-svn: 246532
* Re-apply r246276 - Object: Teach llvm-ar to create symbol table for COFF ↵Rui Ueyama2015-08-283-0/+10
| | | | | | | | | | | short import files This patch includes a fix for a llvm-readobj test. With this patch, the tool does no longer print out COFF headers for the short import file, but that's probably desirable because the header for the short import file is dummy. llvm-svn: 246283
* Rollback r246276 - Object: Teach llvm-ar to create symbol table for COFF ↵Rui Ueyama2015-08-283-10/+0
| | | | | | | | short import files This change caused a test for llvm-readobj to fail. llvm-svn: 246277
* Object: Teach llvm-ar to create symbol table for COFF short import files.Rui Ueyama2015-08-283-0/+10
| | | | | | | | | | | | | COFF short import files are special kind of files that contains only DLL-exported symbol names. That's different from object files because it has no data except symbol names. This change implements a SymbolicFile interface for the short import files so that symbol names can be accessed through that interface. llvm-ar is now able to read the file and create symbol table entries for short import files. llvm-svn: 246276
OpenPOWER on IntegriCloud