Object FIle Representation
At codegen time this is emitted into the ELF file a pair of symbol indices and a weight. In assembly it looks like:
.cg_profile a, b, 32
.cg_profile freq, a, 11
.cg_profile freq, b, 20
When writing an ELF file these are put into a SHT_LLVM_CALL_GRAPH_PROFILE (0x6fff4c02) section as (uint32_t, uint32_t, uint64_t) tuples as (from symbol index, to symbol index, weight).
Differential Revision: https://reviews.llvm.org/D44965
llvm-svn: 333823
Summary:
Same as r332530, move WasmSymbol::dump to an implementation file to avoid linker
issues when the dump function is seen in the header, doesn't get eliminated, and
then linking fails because of the missing dependency.
<rdar://problem/40258137>
Reviewers: sbc100, ncw, paquette, vsk, dschuff
Subscribers: jgravelle-google, aheejin, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D46985
llvm-svn: 332542
Summary:
r332305 added a use of llvm::wasm::toString in llvm::object::WasmSymbol::print,
which is in a header file. It also moves toString to BinaryFormat. This has the
unintended side-effect that any inclusion of Object/Wasm.h now relies on
toString, and needs to required_libraries = BinaryFormat. Thankfully most builds
don't fail with this because print just isn't used and gets eliminated, dropping
the required dependency in the process. Not all builds are so lucky.
Fix this issue by moving print to the corresponding .cpp file.
<rdar://problem/40258137>
Reviewers: sbc100, ncw, paquette
Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D46977
llvm-svn: 332530
The operator == used for exporting a function with a different
name in the DLL compared to the name in the import library
(which is useful for adding linker level aliases for function
in the import library) is a feature distinct and different from
the operator = used for exporting a function with a different
name (both in import library and DLL) than in the implementation
producing the DLL.
When creating an import library using dlltool, from a def file that
contains forwards (Func = OtherDll.Func), this shouldn't affect the
produced import library, which should still behave just as if it
was a normal exported function.
This clears a lot of confusion and subtle misunderstandings, and
avoids a parameter that was used to avoid creating weak aliases
when invoked from lld. (This parameter was added previously due to
the existing conflation of the two features.)
Differential Revision: https://reviews.llvm.org/D46245
llvm-svn: 331859
This is a follow-up to r331272.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
https://reviews.llvm.org/D46290
llvm-svn: 331275
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46290
llvm-svn: 331272
See r331124 for how I made a list of files missing the include.
I then ran this Python script:
for f in open('filelist.txt'):
f = f.strip()
fl = open(f).readlines()
found = False
for i in xrange(len(fl)):
p = '#include "llvm/'
if not fl[i].startswith(p):
continue
if fl[i][len(p):] > 'Config':
fl.insert(i, '#include "llvm/Config/llvm-config.h"\n')
found = True
break
if not found:
print 'not found', f
else:
open(f, 'w').write(''.join(fl))
and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p`
and tried to fix include ordering and whatnot.
No intended behavior change.
llvm-svn: 331184
Summary:
This change fixes https://crbug.com/834474, a build failure caused by
LowerTypeTests not preserving .symver symbol versioning directives for
exported functions. Emit symver information to ThinLTO summary data and
then propagate symver directives for exported functions to the merged
module.
Emitting symver information to the summaries increases the size of
intermediate build artifacts for a Chromium build by less than 0.2%.
Reviewers: pcc
Reviewed By: pcc
Subscribers: tejohnson, mehdi_amini, eraman, llvm-commits, eugenis, kcc
Differential Revision: https://reviews.llvm.org/D45798
llvm-svn: 330387
Clean up the parsing of notes in llvm-readobj, improve bounds checking, and
allow the parsing code to be reused.
Differential Revision: https://reviews.llvm.org/D43958
llvm-svn: 327320
We now check relocations offsets are within range, and the relocation
index is valid.
Also updated tests which contained invalid Wasm files that were
previously not checked.
Differential Revision: https://reviews.llvm.org/D43684
llvm-svn: 326697
This is combination of two patches by Nicholas Wilson:
1. https://reviews.llvm.org/D41954
2. https://reviews.llvm.org/D42495
Along with a few local modifications:
- One change I made was to add the UNDEFINED bit to the binary format
to avoid the extra byte used when writing data symbols. Although this
bit is redundant for other symbols types (i.e. undefined can be
implied if a function or global is a wasm import)
- I prefer to be explicit and consistent and not have derived flags.
- Some field renaming.
- Some reverting of unrelated minor changes.
- No test output differences.
Differential Revision: https://reviews.llvm.org/D43147
llvm-svn: 325860
Peviously we were reporting undefined symbol as being defined
by the IMPORT sections.
This change reports undefined symbols in the same that other
formats do, and also removes the need to store the section
with each symbol (since it can be derived from the symbol
type).
Differential Revision: https://reviews.llvm.org/D43101
llvm-svn: 324770
llvm-objdump could get C feature by ELF::EF_RISCV_RVC e_flag,
so then we don't have to add -mattr=+c on the command line.
Differential Revision: https://reviews.llvm.org/D42629
llvm-svn: 324058
For now, we are not using wasm globals, except for modeling of
the stack points.
Alos, factor out common struct WasmGlobalType, which matches the
name for that tuple in the Wasm spec and rename methods
to "isBindingGlobal", "isTypeGlobal" to avoid ambiguity.
Patch by Nicholas Wilson!
Differential Revision: https://reviews.llvm.org/D42750
llvm-svn: 323901
This (together with the corresponding LLD commit, that contains the
testcase updates) fixes PR35733.
Differential Revision: https://reviews.llvm.org/D41631
llvm-svn: 323035
Get rid of DEBUG_FUNCTION_NAME symbols. When we actually debug
data, maybe we'll want somewhere to put it... but having a symbol
that just stores the name of another symbol seems odd.
It means you have multiple Symbols with the same name, one
containing the actual function and another containing the name!
Store the names in a vector on the WasmObjectFile when reading
them in. Also stash them on the WasmFunctions themselves.
The names are //not// "symbol names" or aliases or anything,
they're just the name that a debugger should show against the
function body itself. NB. The WasmObjectFile stores them so that
they can be exported in the YAML losslessly, and hence the tests
can be precise.
Enforce that the CODE section has been read in before reading
the "names" section. Requires minor adjustment to some tests.
Patch by Nicholas Wilson!
Differential Revision: https://reviews.llvm.org/D42075
llvm-svn: 322741
The ELF specification says that all ELF data structures are aligned to
their natural alignments both in memory and file. That means when we
access mmap'ed ELF files, we could assume that all data structures are
aligned properly.
However, in reality, we assume that the data structures are aligned only
to two bytes because .a files only guarantee that their member files are
aligned to two bytes in archive files. So the data access is already
unaligned.
This patch relaxes the alignment requirement even more, so that we
accept unaligned access to all ELF data structures.
This patch in particular makes lld bug-compatible with icc. Intel C
compiler doesn't seem to care about data alignment and generates unaligned
relocation sections (https://bugs.llvm.org/show_bug.cgi?id=35854).
I also saw another instance of compatibility issues with our internal tool
which creates unaligned section headers.
Because GNU linkers are not picky about alignment, looks like it is
not uncommon that ELF-generating tools create unaligned files.
There is a performance penalty with this patch on host machines on which
unaligned access is expensive. x86 and AArch64 are fine. ARMv6 is a
problem, but I don't think using ARMv6 machines as hosts is common, so I
believe it's not a real problem.
Differential Revision: https://reviews.llvm.org/D41978
llvm-svn: 322407
When weak aliases are used with in same translation
unit we need to be able to directly reference to alias
and not just the thing it is aliases. We do this by
defining both a wasm import and a wasm export in this
case that result in a single Symbol. This change is
a partial revert of rL314245. A corresponding lld
change address the previous issues we had with this.
See: https://github.com/WebAssembly/tool-conventions/issues/34
Differential Revision: https://reviews.llvm.org/D41472
llvm-svn: 321242
Summary:
These fields are useful for lld's gc-sections support
Also remove an unused field.
Subscribers: jfb, dschuff, jgravelle-google, aheejin, sunfish
Differential Revision: https://reviews.llvm.org/D41320
llvm-svn: 320946
From working on lld I've learned this is generally the
preferred way for several reasons (e.g. more concise, improves
encapsulation).
Differential Revision: https://reviews.llvm.org/D41265
llvm-svn: 320906
Summary:
llvm-objdump's Mach-O parser was updated in r306037 to display external
relocations for MH_KEXT_BUNDLE file types. This change extends the Macho-O
parser to display local relocations for MH_PRELOAD files. When used with
the -macho option relocations will be displayed in a historical format.
All tests are passing for llvm, clang, and lld. llvm-objdump builds without
compiler warnings.
rdar://35778019
Reviewers: enderby
Reviewed By: enderby
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41199
llvm-svn: 320832
Most of the -Wsign-compare warnings are due to the fact that
enums are signed by default in the MS ABI, while the
tautological comparison warnings trigger on x86 builds where
sizeof(size_t) is 4 bytes, so N > numeric_limits<unsigned>::max()
is always false.
Differential Revision: https://reviews.llvm.org/D41256
llvm-svn: 320750
This adds the /DEBUG:GHASH option to LLD which will look for
the existence of .debug$H sections in linker inputs and use them
to accelerate type merging. The clang-cl side has already been
added, so this completes the work necessary to begin experimenting
with this feature.
Differential Revision: https://reviews.llvm.org/D40980
llvm-svn: 320719
Summary:
llvm-objdump's Mach-O parser was updated in r306037 to display external
relocations for MH_KEXT_BUNDLE file types. This change extends the Macho-O
parser to display local relocations for MH_PRELOAD files. When used with
the -macho option relocations will be displayed in a historical format.
rdar://35778019
Reviewers: enderby
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41061
llvm-svn: 320532
Summary:
llvm-objdump's Mach-O parser was updated in r306037 to display external
relocations for MH_KEXT_BUNDLE file types. This change extends the Macho-O
parser to display local relocations for MH_PRELOAD files. When used with
the -macho option relocations will be displayed in a historical format.
rdar://35778019
Reviewers: enderby
Reviewed By: enderby
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40867
llvm-svn: 320166
Original change was rL319488.
This was reverted rL319602 due to a gcc 7.1 warning.
Differential Revision: https://reviews.llvm.org/D40772
llvm-svn: 319626
