Summary:
getRelocatedValue may compute incorrect value for SHT_RELA-typed relocation entries.
// DWARFDataExtractor.cpp
uint64_t DWARFDataExtractor::getRelocatedValue(uint32_t Size, uint32_t *Off,
...
// This formula is correct for REL, but may be incorrect for RELA if the value
// stored in the location (getUnsigned(Off, Size)) is not zero.
return getUnsigned(Off, Size) + Rel->Value;
In this patch, we
* refactor these visit* functions to include a new parameter `uint64_t A`.
Since these visit* functions are no longer used as visitors, rename them to resolve*.
+ REL: A is used as the addend. A is the value stored in the location where the
relocation applies: getUnsigned(Off, Size)
+ RELA: The addend encoded in RelocationRef is used, e.g. getELFAddend(R)
* and add another set of supports* functions to check if a given relocation type is handled.
DWARFObjInMemory uses them to fail early.
Reviewers: echristo, dblaikie
Reviewed By: echristo
Subscribers: mgorny, aprantl, aheejin, fedor.sergeev, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57939
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356729 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, this fails with many tools, e.g.
$ clang -fembed-bitcode-marker -c -o test.o test.c
$ nm test.o
nm: test.o The file was not recognized as a valid object file
-fembed-bitcode-marker creates a LLVM,bitcode section consisting of a single
byte. When reading the object file, IRObjectFile::findBitcodeInObject succeeds,
causing SymbolicFile::createSymbolicFile to try to read the "bitcode" rather
than using the outer Mach-O data - when then fails.
Fix this by making findBitcodeInObject return an error if the section size <= 1.
Patched by: Nicholas Allegra
Differential Revision: https://reviews.llvm.org/D44373
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356718 91177308-0d34-0410-b5e6-96231b3b80d8
Prior to this change, the "Symbol" field of a relocation would always be
assumed to be a symbol name, and if no such symbol existed, the
relocation would reference index 0. This confused me when I tried to use
a literal symbol index in the field: since "0x1" was not a known symbol
name, the symbol index was set as 0. This change falls back to treating
unknown symbol names as integers, and emits an error if the name is not
found and the string is not an integer.
Note that the Symbol field is optional, so if a relocation doesn't
reference a symbol, it shouldn't be specified. The new error required a
number of test updates.
Reviewed by: grimar, ruiu
Differential Revision: https://reviews.llvm.org/D58510
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355938 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch will obtain the section name for symbols that refer to a section. Prior to this patch the Name field for STT_SECTIONs was blank, now it is populated.
Before:
```
Symbol table '.symtab' contains 6 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 SECTION LOCAL DEFAULT 1
2: 0000000000000000 0 SECTION LOCAL DEFAULT 3
3: 0000000000000000 0 SECTION LOCAL DEFAULT 4
4: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _GLOBAL_OFFSET_TABLE_
5: 0000000000000000 0 TLS GLOBAL DEFAULT UND sym
```
With this patch:
```
Symbol table '.symtab' contains 6 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 SECTION LOCAL DEFAULT 1 .text
2: 0000000000000000 0 SECTION LOCAL DEFAULT 3 .data
3: 0000000000000000 0 SECTION LOCAL DEFAULT 4 .bss
4: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _GLOBAL_OFFSET_TABLE_
5: 0000000000000000 0 TLS GLOBAL DEFAULT UND sym
```
This fixes PR40788
Reviewers: jhenderson, rupprecht, espindola
Reviewed By: rupprecht
Subscribers: emaste, javed.absar, arichardson, MaskRay, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58796
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355207 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Changes from using a total ordering of known sections to using a
dependency graph approach. This allows our tools to accept and process
binaries that are compliant with the spec and tool conventions that
would have been previously rejected. It also means our own tools can
do less work to enforce an artificially imposed ordering. Using a
general mechanism means fewer special cases and exceptions in the
ordering logic.
Reviewers: aheejin, dschuff
Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58312
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354426 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The previous implementation reported `.comment` sections as '?'
GNU uses 'n' which means "The symbol is a debugging symbol." `.note` sections are represented as 'n' too.
The test related to this change was updated to CHECK-NEXT to ensure
order and that we did not miss any symbols in the dump.
Reviewers: jhenderson
Reviewed By: jhenderson
Subscribers: rupprecht, llvm-commits
Differential Revision: https://reviews.llvm.org/D57544
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@352891 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Previously, llvm-nm would report symbols for .debug and .note sections as: '?' with an empty section name:
```
00000000 ?
00000000 ?
...
```
With this patch the output more closely resembles GNU nm:
```
00000000 N .debug_abbrev
00000000 n .note.GNU-stack
...
```
This patch calls `getSectionName` for sections that belong to symbols of type `ELF::STT_SECTION`, which returns the name of the section from the section string table.
Reviewers: Bigcheese, davide, jhenderson
Reviewed By: davide, jhenderson
Subscribers: rupprecht, jhenderson, llvm-commits
Differential Revision: https://reviews.llvm.org/D57105
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@352785 91177308-0d34-0410-b5e6-96231b3b80d8
I faced with the fact that obj2yaml does not dump the sh_entsize field.
A problem arose when I tried to dump ELF versioning sections.
This is close to what D50235 did, but D50235 did the change for yaml2obj, and now
I had to do the same for obj2yaml.
Differential revision: https://reviews.llvm.org/D57229
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@352373 91177308-0d34-0410-b5e6-96231b3b80d8
When --section-headers is used, GNU objdump prints both LMA and VMA for sections.
llvm-objdump does not do that what makes it's output be slightly inconsistent.
Patch teaches llvm-objdump to print LMA/VMA for ELF file formats.
The behavior for other formats remains unchanged.
Differential revision: https://reviews.llvm.org/D57146
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@352366 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
guessLibraryShortName() separates a full Mach-O dylib install name path
into a short name and a dyld image suffix. The short name is the name
of the dylib without its path or extension. The dyld image suffix is a
string used by dyld to load variants of dylibs if available at runtime;
for example, "when binding this process, load 'debug' variants of all
required dylibs." dyld knows exactly what the image suffix is, but
by convention diagnostic tools such as llvm-nm attempt to guess suffix
names by looking at the install name path.
These dyld image suffixes are separated from the short name by a '_'
character. Because the '_' character is commonly used to separate words
in filenames guessLibraryShortName() cannot reliably separate a dylib's
short name from an arbitrary image suffix; imagine if both the short
name and the suffix contains an '_' character! To better deal with this
ambiguity, guessLibraryShortName() will recognize only "_debug" and
"_profile" as valid Suffix values. Calling code needs to be tolerant of
guessLibraryShortName() guessing incorrectly.
The previous implementation of guessLibraryShortName() did not allow
'_' characters to appear in short names. When present, the short name
would be truncated, e.g., "libcompiler_rt" => "libcompiler". This
change allows "libcompiler_rt" and "libcompiler_rt_debug" to both be
recognized as "libcompiler_rt".
rdar://47412244
Reviewers: kledzik, lhames, pete
Reviewed By: pete
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D56978
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@352104 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Import libraries as created by llvm-dlltool always use the same archive
member name for every object file (namely, the DLL library name). Ensure
that long names are not repeatedly stored in the string table.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D55860
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@349637 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch checks if the section order is correct when reading a wasm
object file in `WasmObjectFile` and converting YAML to wasm object in
yaml2wasm. (It is not possible to check when reading YAML because it is
handled exclusively by the YAML reader.)
This checks the ordering of all known sections (core sections + known
custom sections). This also adds section ID DataCount section that will
be scheduled to be added in near future.
Reviewers: sbc100
Subscribers: dschuff, mgorny, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D54924
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@349221 91177308-0d34-0410-b5e6-96231b3b80d8
Update tests using llvm-objdump since check strings don't
match anymore due to the extra `O` in place. This is a
followup for rL346610.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@346611 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This updates generated binaries and corresponding test cases up to date
after applying FixFunctionBitcasts pass.
Reviewers: sbc100
Subscribers: dschuff, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D54070
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@346286 91177308-0d34-0410-b5e6-96231b3b80d8
* Support writing the DARWIN64 symbol table format.
* In darwin archives, emit a symbol table whenever requested, even
when there are no members, as the apple linker will abort if given
an archive without a symbol table.
Added tests for same, and also simplified and moved the GNU 64-bit
symbol table test into archive-symtab.test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@344183 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The POSIX spec says:
```
If the −t option is used with the −v option, the standard output format shall be:
"%s %u/%u %u %s %d %d:%d %d %s\n", <member mode>, <user ID>,
<group ID>, <number of bytes in member>,
<abbreviated month>, <day-of-month>, <hour>,
<minute>, <year>, <file>
where:
...
<abbreviated month>
Equivalent to the format of the %b conversion specification format in date.
<day-of-month>
Equivalent to the format of the %e conversion specification format in date.
<hour> Equivalent to the format of the %H conversion specification format in date.
<minute> Equivalent to the format of the %M conversion specification format in date.
<year> Equivalent to the format of the %Y conversion specification format in date.
```
This actually used to be the format printed by llvm-ar. It was apparently accidentally changed (see r207385 followed by comments in r207387). This makes it conform to GNU ar for easier replacement.
Reviewers: MaskRay
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D52940
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343901 91177308-0d34-0410-b5e6-96231b3b80d8
This change ensures that the (membername,timestamp) tuple uniquely
identifies an entry in an archive for format=darwin, in deterministic
mode (which is the default).
That, then, enables lldb and dsymutil to locate the appropriate object
within the archive.
Differential Revision: https://reviews.llvm.org/D47659
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343805 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
GNU nm (and other nm implementations, such as "go tool nm") prints an explicit "no symbols" message when an object file has no symbols. Currently llvm-nm just doesn't print anything. Adding an explicit "no symbols" message will allow llvm-nm to be used in place of nm: some scripts and build processes use `nm <file> | grep "no symbols"` as a test to see if a file has no symbols. It will also be more familiar to anyone used to nm.
That said, the format implemented here is slightly different, in that it doesn't print the tool name in the message (which IMHO is not useful to include).
Demo:
```
$ for nm in nm bin/llvm-nm ; do echo "nm implementation: $nm"; $nm /tmp/foo{1,2}.o; echo; done
nm implementation: nm
/tmp/foo1.o:
nm: /tmp/foo1.o: no symbols
/tmp/foo2.o:
0000000000000000 T foo2
nm implementation: bin/llvm-nm
/tmp/foo1.o:
no symbols
/tmp/foo2.o:
0000000000000000 T foo2
```
Reviewers: MaskRay
Reviewed By: MaskRay
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D52810
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343742 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This affects what sections are displayed as "DATA" in llvm-objdump.
The other user llvm-size is unaffected.
Before, a "TEXT" section is also "DATA", which seems weird.
The sh_flags condition matches that of bfd's SEC_DATA but the sh_type
condition uses (== SHF_PROGBITS) instead of bfd's (!= SHT_NOBITS).
bfd's SEC_DATA is not appealing as so many sections will be shown as DATA.
Reviewers: jyknight, Bigcheese
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D48472
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335405 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
"Unknown" for platforms that were not manually added into the switch
did not make sense at all. Now it prints Target + addend for all
elf-machines that were not explicitly mentioned.
Addresses PR21059 and PR25124.
Original author: fedor.sergeev
Reviewers: jyknight, espindola, fedor.sergeev
Reviewed By: jyknight
Subscribers: eraman, dcederman, jfb, dschuff, aheejin, llvm-commits
Differential Revision: https://reviews.llvm.org/D36464
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@333726 91177308-0d34-0410-b5e6-96231b3b80d8
On win32 we use lit's executeBuiltinEcho to implement the
echo command and this version only currently supports flags
that are separate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@333495 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: The final -wasm component has been the default for some time now.
Subscribers: jfb, dschuff, jgravelle-google, eraman, aheejin, JDevlieghere, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D46342
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@332007 91177308-0d34-0410-b5e6-96231b3b80d8
This allows syntax like:
$ llvm-ar -c -r -u file.a file.o
This is in addition to the other formats that are already supported:
$ llvm-ar cru file.a file.o
$ llvm-ar -cru file.a file.o
Patch by Tom Anderson!
Differential Revision: https://reviews.llvm.org/D44452
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328716 91177308-0d34-0410-b5e6-96231b3b80d8
