[WebAssembly][Object] Support more elem segment flags (#123427)

Some tools (e.g. Rust tooling) produce element segment descriptors with
neither
elemkind or element type descriptors, but with init

[WebAssembly][Object] Support more elem segment flags (#123427)

Some tools (e.g. Rust tooling) produce element segment descriptors with
neither
elemkind or element type descriptors, but with init exprs instead of
func indices
(this is with the flags value of 4 in

https://webassembly.github.io/spec/core/binary/modules.html#element-section).
LLVM doesn't fully model reference types or the various ways to
initialize element
segments, but we do want to correctly parse and skip over all type
sections, so
this change updates the object parser to handle that case, and refactors
for more
clarity.

The test file is updated to include one additional elem segment with a
flags value
of 4, an initializer value of (32.const 0) and an empty vector.

Also support parsing files that export imported (undefined) functions.

show more ...

[Support][Error] Add ErrorAsOutParameter constructor that takes an Error by ref.

ErrorAsOutParameter's Error* constructor supports cases where an Error might not
be passed in (because in the calling

[Support][Error] Add ErrorAsOutParameter constructor that takes an Error by ref.

ErrorAsOutParameter's Error* constructor supports cases where an Error might not
be passed in (because in the calling context it's known that this call won't
fail). Most clients always have an Error present however, and for them an Error&
overload is more convenient.

show more ...

[Object] Remove unused includes (NFC) (#116750)

Identified with misc-include-cleaner.

[llvm] Remove redundant control flow statements (NFC) (#115831)

Identified with readability-redundant-control-flow.

[WebAssembly] Remove WASM_FEATURE_PREFIX_REQUIRED (NFC) (#113729)

This has not been emitted since

https://github.com/llvm/llvm-project/commit/3f34e1b883351c7d98426b084386a7aa762aa366.

The corr

[WebAssembly] Remove WASM_FEATURE_PREFIX_REQUIRED (NFC) (#113729)

This has not been emitted since

https://github.com/llvm/llvm-project/commit/3f34e1b883351c7d98426b084386a7aa762aa366.

The corresponding proposed tool-conventions change:
https://github.com/WebAssembly/tool-conventions/pull/236

show more ...

[lld][WebAssembly] Report undefined symbols in -shared/-pie builds (#75242)

Previously we would ignore all undefined symbols when using
`-shared` or `-pie`. All undefined symbols would be treated a

[lld][WebAssembly] Report undefined symbols in -shared/-pie builds (#75242)

Previously we would ignore all undefined symbols when using
`-shared` or `-pie`. All undefined symbols would be treated as imports
regardless of whether those symbols we defined in any shared library.
With this change we now track symbol in shared libraries and report
undefined symbols in the main program by default.
The old behavior is still available via the
`--unresolved-symbols=import-dynamic` command line flag.

This rationale for allowing this type of breaking change is that `-pie`
and `-shared` are both still experimental will warn as such, unless
`--experimental-pic` is passed.

As part of this change the linker now models shared library symbols
via new SharedFunctionSymbol and SharedDataSymbol types.

I've also added a new `--no-shlib-sigcheck` option that bypassed the
checking of functions signature in shared libraries. This is
specifically required by emscripten the case where the imports/exports
of shared libraries have been modified by via JS type legalization (this
is only needed when targeting old JS engines where bigint is not yet
available

See https://github.com/emscripten-core/emscripten/issues/18198

show more ...

[WebAssembly] Add exnref type (#93586)

This adds (back) the exnref type restored in the new EH proposal adopted
in Oct 2023 CG meeting:

https://github.com/WebAssembly/exception-handling/blob/mai

[WebAssembly] Add exnref type (#93586)

This adds (back) the exnref type restored in the new EH proposal adopted
in Oct 2023 CG meeting:

https://github.com/WebAssembly/exception-handling/blob/main/proposals/exception-handling/Exceptions.md:x

show more ...

[Object][Wasm] Use offset instead of index for Global address and store size (#81781)

Currently the address reported by binutils for a global is its index;
but its offset (in the file or section) i

[Object][Wasm] Use offset instead of index for Global address and store size (#81781)

Currently the address reported by binutils for a global is its index;
but its offset (in the file or section) is more useful for binary size
attribution.
This PR treats globals similarly to functions, and tracks their offset
and size. It also centralizes the logic differentiating linked from object
and dylib files (where section addresses are 0).

show more ...

[llvm-nm][WebAssembly] Print function symbol sizes (#81315)

nm already prints sizes for data symbols. Do that for function symbols
too, and update objdump to also print size information.

Implem

[llvm-nm][WebAssembly] Print function symbol sizes (#81315)

nm already prints sizes for data symbols. Do that for function symbols
too, and update objdump to also print size information.

Implements item 3 from https://github.com/llvm/llvm-project/issues/76107

show more ...

[Object][WebAssembly] Improve error on invalid relocation (#81203)

See https://github.com/emscripten-core/emscripten/issues/21140

[Object][Wasm] Generate symbol info from name section names (#81063)

Currently symbol info is generated from a linking section or from export
names. This PR generates symbols in a WasmObjectFile fr

[Object][Wasm] Generate symbol info from name section names (#81063)

Currently symbol info is generated from a linking section or from export
names. This PR generates symbols in a WasmObjectFile from the name
section as well, which allows tools like objdump and nm to show useful
information for more linked binaries. There are some limitations:
most notably that we don't assume any particular ABI, so we don't get
detailed information about data symbols if the segments are merged
(which is the default).

Covers most of the desired functionality from #76107

show more ...

[Object][Wasm] Use file offset for section addresses in linked wasm files (#80529)

Wasm has no unified virtual memory space as other object formats and
architectures do, so previously WasmObjectFil

[Object][Wasm] Use file offset for section addresses in linked wasm files (#80529)

Wasm has no unified virtual memory space as other object formats and
architectures do, so previously WasmObjectFile reported 0 for all
section addresses, and until 428cf71ff used section offsets for function
symbols. Now we use file offsets for function symbols, and this change
switches section addresses to do the same (in linked files). The main
result of this is that objdump now reports VMAs in section listings, and
also uses file offets rather than section offsets when disassembling
linked binaries (matching the behavior of other disassemblers and stack
traces produced by browwsers). To make this work, this PR also updates
objdump's generation of synthetics fallback symbols to match lib/Object
and also correctly plumbs symbol types for regular and dummy symbols
through to the backend to avoid needing special knowledge of address 0.

This also paves the way for generating symbols from name sections rather
than symbol tables or imports (see #76107) by allowing the
disassembler's synthetic fallback symbols match the name-section
generated symbols (in a followup PR).

show more ...

[Object][Wasm] Move WasmSymbolInfo directly into WasmSymbol (NFC) (#80219)

Move the WasmSymbolInfos from their own vector on the WasmLinkingData
directly into the WasmSymbol object. Removing the co

[Object][Wasm] Move WasmSymbolInfo directly into WasmSymbol (NFC) (#80219)

Move the WasmSymbolInfos from their own vector on the WasmLinkingData
directly into the WasmSymbol object. Removing the const-ref to an
external object allows the vector of WasmSymbols to be safely
expanded/reallocated; generating symbol info from the name section will
require this, as the numbers of function and data segment names are
stored separately.

This is a step toward generating symbol information from name sections
for #76107

show more ...

[Object][Wasm] Allow parsing of GC types in type and table sections (#79235)

This change allows a WasmObjectFile to be created from a wasm file even
if it uses typed funcrefs and GC types. It does

[Object][Wasm] Allow parsing of GC types in type and table sections (#79235)

This change allows a WasmObjectFile to be created from a wasm file even
if it uses typed funcrefs and GC types. It does not significantly change how
lib/Object models its various internal types (e.g. WasmSignature,
WasmElemSegment), so LLVM does not really "support" or understand such
files, but it is sufficient to parse the type, global and element sections, discarding
types that are not understood. This is useful for low-level binary tools such as
nm and objcopy, which use only limited aspects of the binary (such as function
definitions) or deal with sections as opaque blobs.

This is done by allowing `WasmValType` to have a value of `OTHERREF`
(representing any unmodeled reference type), and adding a field to
`WasmSignature` indicating it's a placeholder for an unmodeled reference
type (since there is a 1:1 correspondence between WasmSignature objects
and types in the type section).
Then the object file parsers for the type and element sections are expanded
to parse encoded reference types and discard any unmodeled fields.

show more ...

[WebAssembly] Use ValType instead of integer types to model wasm tables (#78012)

LLVM models some features found in the binary format with raw integers
and others with nested or enumerated types. T

[WebAssembly] Use ValType instead of integer types to model wasm tables (#78012)

LLVM models some features found in the binary format with raw integers
and others with nested or enumerated types. This PR switches modeling of
tables and segments to use wasm::ValType rather than uint32_t. This NFC
change is in preparation for modeling more reference types, but IMO is
also cleaner and closer to the spec.

show more ...

Reland "[WebAssembly][Object]Use file offset as function symbol address for linked files (#76198)"

WebAssembly doesn't have a single virtual memory space the way other object
formats or architecture

Reland "[WebAssembly][Object]Use file offset as function symbol address for linked files (#76198)"

WebAssembly doesn't have a single virtual memory space the way other object
formats or architectures do, so "addresses" mean different things depending
on the context.
Function symbol addresses in object files are offsets from the start of the code
section. This is good for linking and relocation. However when dealing with
linked binaries, offsets from the start of the file/module are more often
used (e.g. for stack traces in browsers), and are more useful for use
cases like binary size attribution. This PR changes Object to use
the file offset instead of the section offset for function symbols, but
only for linked (non-DSO) files.

This is a reland of fc5f51cf with a fix for the MSan failure (it was not caused
by this change, but it was revealed by the new tests).

show more ...

Revert "[WebAssembly][Object]Use file offset as function symbol address for linked files (#76198)"

This reverts commit fc5f51cf5af4364b38bf22e491d46e1e892ade0c.

Reason: Broke the sanitizer buildbot

Revert "[WebAssembly][Object]Use file offset as function symbol address for linked files (#76198)"

This reverts commit fc5f51cf5af4364b38bf22e491d46e1e892ade0c.

Reason: Broke the sanitizer buildbot -
https://lab.llvm.org/buildbot/#/builders/5/builds/39751/steps/12/logs/stdio

show more ...

[WebAssembly][Object]Use file offset as function symbol address for linked files (#76198)

WebAssembly doesn't have a single virtual memory space the way other
object formats or architectures do, so

[WebAssembly][Object]Use file offset as function symbol address for linked files (#76198)

WebAssembly doesn't have a single virtual memory space the way other
object formats or architectures do, so "addresses" mean different things
depending on the context.
Function symbol addresses in object files are offsets from the start of
the code section. This is good for linking and relocation. However when
dealing with linked binaries, offsets from the start of the file/module
are more often used (e.g. for stack traces in browsers), and are more
useful for use cases like binary size attribution. This PR changes
Object to use the file offset instead of the section offset for function
symbols, but only for linked (non-DSO) files.

This implements item number 4 from #76107

show more ...

[WebAssembly] Add bounds check in parseCodeSection (#76407)

This is needed as otherwise `Ctx.Ptr` will be incremented to a position
outside it's available buffer, which is being used to read values

[WebAssembly] Add bounds check in parseCodeSection (#76407)

This is needed as otherwise `Ctx.Ptr` will be incremented to a position
outside it's available buffer, which is being used to read values e.g.
https://github.com/llvm/llvm-project/blob/966d564e43e650b9c34f9c67829d3947f52add91/llvm/lib/Object/WasmObjectFile.cpp#L1469

Fixes: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28856

Signed-off-by: David Korczynski <david@adalogics.com>

show more ...

[WebAssembly][Object] Record section start offsets at start of payload (#76188)

LLVM ObjectFile currently records the start offsets of sections as the
start of the section header, whereas most othe

[WebAssembly][Object] Record section start offsets at start of payload (#76188)

LLVM ObjectFile currently records the start offsets of sections as the
start of the section header, whereas most other tools (WABT, emscripten,
wasm-tools) record it as the start of the section content, after the
header. This affects binutils tools such as objdump and nm, but not
compilation/assembly (since that is driven by symbols and assembler
labels which already have their values inside the section payload rather
in the header. This patch updates LLVM to match the other tools.

show more ...

[WebAssembly] Add symbol information for shared libraries (#75238)

The current (experimental) spec for WebAssembly shared libraries does
not include a full symbol table like the object format. This

[WebAssembly] Add symbol information for shared libraries (#75238)

The current (experimental) spec for WebAssembly shared libraries does
not include a full symbol table like the object format. This change
extracts symbol information from the normal wasm exports.

This is the first step in having the linker report undefined symbols
when linking with shared libraries. The current behaviour is to ignore
all undefined symbols when linking with `-pie` or `-shared`.

See https://github.com/emscripten-core/emscripten/issues/18198

show more ...

[llvm] Use StringRef::{starts,ends}_with (NFC) (#74956)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::

[llvm] Use StringRef::{starts,ends}_with (NFC) (#74956)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

show more ...

[WebAssembly] Allow absolute symbols in the linking section (symbol table) (#67493)

Fixes a crash in `-Wl,-emit-relocs` where the linker was not able to
write linker-synthetic absolute symbols to t

[WebAssembly] Allow absolute symbols in the linking section (symbol table) (#67493)

Fixes a crash in `-Wl,-emit-relocs` where the linker was not able to
write linker-synthetic absolute symbols to the symbol table.

This change adds a new symbol flag (`WASM_SYMBOL_ABS`), which means that
the symbol's offset is absolute and not relative to a given segment.
Such symbols include `__stack_low` and `__stack_low`.

Note that wasm object files never contains such symbols, only binaries
linked with `-Wl,-emit-relocs`.

Fixes: #67111

show more ...

[llvm-nm][WebAssembly] Report the size of data symbols

Fixes: https://github.com/llvm/llvm-project/issues/58839

Differential Revision: https://reviews.llvm.org/D158799

[WebAssembly][Objcopy] Write output section headers identically to inputs

Previously when objcopy generated section headers, it padded the LEB
that encodes the section size out to 5 bytes, matching

[WebAssembly][Objcopy] Write output section headers identically to inputs

Previously when objcopy generated section headers, it padded the LEB
that encodes the section size out to 5 bytes, matching the behavior of
clang. This is correct, but results in a binary that differs from the
input. This can sometimes have undesirable consequences (e.g. breaking
source maps).

This change makes the object reader remember the size of the LEB
encoding in the section header, so that llvm-objcopy can reproduce it
exactly. For sections not read from an object file (e.g. that
llvm-objcopy is adding itself), pad to 5 bytes.

Reviewed By: jhenderson

Differential Revision: https://reviews.llvm.org/D155535

show more ...