History log of /llvm-project/llvm/lib/MC/MCContext.cpp (Results 76 – 100 of 360)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 1def2579 08-Jul-2021 David Blaikie <dblaikie@gmail.com>

PR51018: Remove explicit conversions from SmallString to StringRef to future-proof against C++23

C++23 will make these conversions ambiguous - so fix them to make the
codebase forward-compatible wit

PR51018: Remove explicit conversions from SmallString to StringRef to future-proof against C++23

C++23 will make these conversions ambiguous - so fix them to make the
codebase forward-compatible with C++23 (& a follow-up change I've made
will make this ambiguous/invalid even in <C++23 so we don't regress
this & it generally improves the code anyway)

show more ...


Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1
# 165321b3 12-May-2021 Tomas Matheson <tomas.matheson@arm.com>

[MC][ELF] Emit unique sections for different flags

Global values imply flags such as readable, writable, executable for the
sections that they will be placed in. Currently MC places all such
entries

[MC][ELF] Emit unique sections for different flags

Global values imply flags such as readable, writable, executable for the
sections that they will be placed in. Currently MC places all such
entries into the same section, using the first set of flags seen. This
can lead to situations in LTO where a writable global is placed in the
same named section as a readable global from another file, and the
section may not be marked writable.

D72194 ensures that mergeable globals with explicit sections are placed
in separate sections with compatible entry size, by emitting the
`unique` assembly syntax where appropriate. This change extends that
approach to include section flags, so that globals with different
section flags are emitted in separate unique sections.

Differential revision: https://reviews.llvm.org/D100944

show more ...


# c2f819af 23-May-2021 Philipp Krones <philipp.krones@embecosm.com>

[MC] Refactor MCObjectFileInfo initialization and allow targets to create MCObjectFileInfo

This makes it possible for targets to define their own MCObjectFileInfo.
This MCObjectFileInfo is then used

[MC] Refactor MCObjectFileInfo initialization and allow targets to create MCObjectFileInfo

This makes it possible for targets to define their own MCObjectFileInfo.
This MCObjectFileInfo is then used to determine things like section alignment.

This is a follow up to D101462 and prepares for the RISCV backend defining the
text section alignment depending on the enabled extensions.

Reviewed By: MaskRay

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

show more ...


Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3
# 3b8d2be5 27-Feb-2021 Sam Clegg <sbc@chromium.org>

Reland: "[lld][WebAssembly] Initial support merging string data"

This change was originally landed in: 5000a1b4b9edeb9e994f2a5b36da8d48599bea49
It was reverted in: 061e071d8c9b98526f35cad55a918a4f16

Reland: "[lld][WebAssembly] Initial support merging string data"

This change was originally landed in: 5000a1b4b9edeb9e994f2a5b36da8d48599bea49
It was reverted in: 061e071d8c9b98526f35cad55a918a4f1615afd4

This change adds support for a new WASM_SEG_FLAG_STRINGS flag in
the object format which works in a similar fashion to SHF_STRINGS
in the ELF world.

Unlike the ELF linker this support is currently limited:
- No support for SHF_MERGE (non-string merging)
- Always do full tail merging ("lo" can be merged with "hello")
- Only support single byte strings (p2align 0)

Like the ELF linker merging is only performed at `-O1` and above.

This fixes part of https://bugs.llvm.org/show_bug.cgi?id=48828,
although crucially it doesn't not currently support debug sections
because they are not represented by data segments (they are custom
sections)

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

show more ...


# 061e071d 10-May-2021 Nico Weber <thakis@chromium.org>

Revert "[lld][WebAssembly] Initial support merging string data"

This reverts commit 5000a1b4b9edeb9e994f2a5b36da8d48599bea49.
Breaks tests, see https://reviews.llvm.org/D97657#2749151

Easily repros

Revert "[lld][WebAssembly] Initial support merging string data"

This reverts commit 5000a1b4b9edeb9e994f2a5b36da8d48599bea49.
Breaks tests, see https://reviews.llvm.org/D97657#2749151

Easily repros locally with `ninja check-llvm-mc-webassembly`.

show more ...


# 5000a1b4 27-Feb-2021 Sam Clegg <sbc@chromium.org>

[lld][WebAssembly] Initial support merging string data

This change adds support for a new WASM_SEG_FLAG_STRINGS flag in
the object format which works in a similar fashion to SHF_STRINGS
in the ELF w

[lld][WebAssembly] Initial support merging string data

This change adds support for a new WASM_SEG_FLAG_STRINGS flag in
the object format which works in a similar fashion to SHF_STRINGS
in the ELF world.

Unlike the ELF linker this support is currently limited:
- No support for SHF_MERGE (non-string merging)
- Always do full tail merging ("lo" can be merged with "hello")
- Only support single byte strings (p2align 0)

Like the ELF linker merging is only performed at `-O1` and above.

This fixes part of https://bugs.llvm.org/show_bug.cgi?id=48828,
although crucially it doesn't not currently support debug sections
because they are not represented by data segments (they are custom
sections)

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

show more ...


# 632ebc4a 05-May-2021 Philipp Krones <philipp.krones@embecosm.com>

[MC] Untangle MCContext and MCObjectFileInfo

This untangles the MCContext and the MCObjectFileInfo. There is a circular
dependency between MCContext and MCObjectFileInfo. Currently this dependency
a

[MC] Untangle MCContext and MCObjectFileInfo

This untangles the MCContext and the MCObjectFileInfo. There is a circular
dependency between MCContext and MCObjectFileInfo. Currently this dependency
also exists during construction: You can't contruct a MOFI without a MCContext
without constructing the MCContext with a dummy version of that MOFI first.
This removes this dependency during construction. In a perfect world,
MCObjectFileInfo wouldn't depend on MCContext at all, but only be stored in the
MCContext, like other MC information. This is future work.

This also shifts/adds more information to the MCContext making it more
available to the different targets. Namely:

- TargetTriple
- ObjectFileType
- SubtargetInfo

Reviewed By: MaskRay

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

show more ...


# 87bbf3d1 05-Mar-2021 Chen Zheng <czhengsz@cn.ibm.com>

[XCOFF][DebugInfo] support DWARF for XCOFF for assembly output.

Reviewed By: jasonliu

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


# 10392825 02-Mar-2021 Yuanfang Chen <yuanfang.chen@sony.com>

Fix memleak for 5de2d189e6ad4

Fix typo `release` -> `reset`


Revision tags: llvmorg-12.0.0-rc2
# 5de2d189 23-Feb-2021 Yuanfang Chen <yuanfang.chen@sony.com>

[Diagnose] Unify MCContext and LLVMContext diagnosing

The situation with inline asm/MC error reporting is kind of messy at the
moment. The errors from MC layout are not reliably propagated and users

[Diagnose] Unify MCContext and LLVMContext diagnosing

The situation with inline asm/MC error reporting is kind of messy at the
moment. The errors from MC layout are not reliably propagated and users
have to specify an inlineasm handler separately to get inlineasm
diagnose. The latter issue is not a correctness issue but could be improved.

* Kill LLVMContext inlineasm diagnose handler and migrate it to use
DiagnoseInfo/DiagnoseHandler.
* Introduce `DiagnoseInfoSrcMgr` to diagnose SourceMgr backed errors. This
covers use cases like inlineasm, MC, and any clients using SourceMgr.
* Move AsmPrinter::SrcMgrDiagInfo and its instance to MCContext. The next step
is to combine MCContext::SrcMgr and MCContext::InlineSrcMgr because in all
use cases, only one of them is used.
* If LLVMContext is available, let MCContext uses LLVMContext's diagnose
handler; if LLVMContext is not available, MCContext uses its own default
diagnose handler which just prints SMDiagnostic.
* Change a few clients(Clang, llc, lldb) to use the new way of reporting.

Reviewed By: MaskRay

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

show more ...


# 508aa69e 11-Feb-2021 Wouter van Oortmerssen <aardappel@gmail.com>

[WebAssembly] Fix assert in lookup of section symbols

Fixes assert in: https://bugs.llvm.org/show_bug.cgi?id=49036

getWasmSection creates sections if they don't exist, but doesn't add them to the S

[WebAssembly] Fix assert in lookup of section symbols

Fixes assert in: https://bugs.llvm.org/show_bug.cgi?id=49036

getWasmSection creates sections if they don't exist, but doesn't add them to the Symbols table. This may cause problems in subsequent calls to getOrCreateSymbol which checks this table, the calls createSymbol assuming it doesn't exist, which then checks UsedNames and finds out it does exist, causing an assert on trying to rename a non-temp symbol.

I tried also fixing the somewhat unintuitive forced suffixing (adding `0`), but it turns out that WasmObjectWriter currently assumes these section symbols are unique, so that may have to be a separate fix: https://bugs.llvm.org/show_bug.cgi?id=49252

Also worth noting is that getWasmSection calling createSymbol may not be correct to start with, given that createSymbol seems to assume it is creating non-section symbols. But again, for a future fix.

Related: where some of this was introduced: https://github.com/llvm/llvm-project/commit/8d396acac3bc21f688ac707bb42e4698dbdcab7e

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

show more ...


# 5517923b 18-Feb-2021 Chen Zheng <czhengsz@cn.ibm.com>

[XCOFF][NFC] make csect properties optional for getXCOFFSection

We are going to support debug sections for XCOFF. So the csect
properties are not necessary. This patch makes these properties
optiona

[XCOFF][NFC] make csect properties optional for getXCOFFSection

We are going to support debug sections for XCOFF. So the csect
properties are not necessary. This patch makes these properties
optional.

Reviewed By: hubert.reinterpretcast

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

show more ...


Revision tags: llvmorg-11.1.0, llvmorg-11.1.0-rc3
# 16af9739 01-Feb-2021 Petr Hosek <phosek@google.com>

[MC][ELF] Support for zero flag section groups

This change introduces support for zero flag ELF section groups to LLVM.
LLVM already supports COMDAT sections, which in ELF are a special type
of ELF

[MC][ELF] Support for zero flag section groups

This change introduces support for zero flag ELF section groups to LLVM.
LLVM already supports COMDAT sections, which in ELF are a special type
of ELF section groups. These are generally useful to enable linker GC
where you want a group of sections to always travel together, that is to
be either retained or discarded as a whole, but without the COMDAT
semantics. Other ELF assemblers already support zero flag ELF section
groups and this change helps us reach feature parity.

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

show more ...


Revision tags: llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1
# d9a0c40b 21-Dec-2020 Fangrui Song <i@maskray.me>

[MC] Split MCContext::createTempSymbol, default AlwaysAddSuffix to true, and add comments

CanBeUnnamed is rarely false. Splitting to a createNamedTempSymbol makes the
intention clearer and matches t

[MC] Split MCContext::createTempSymbol, default AlwaysAddSuffix to true, and add comments

CanBeUnnamed is rarely false. Splitting to a createNamedTempSymbol makes the
intention clearer and matches the direction of reverted r240130 (to drop the
unneeded parameters).

No behavior change.

show more ...


# 8ffda237 21-Dec-2020 Fangrui Song <i@maskray.me>

MCContext::reportError: don't call report_fatal_error

Errors from MCAssembler, MCObjectStreamer and *ObjectWriter typically cause a crash:

```
% cat c.c
int bar;
extern int foo __attribute__((alias

MCContext::reportError: don't call report_fatal_error

Errors from MCAssembler, MCObjectStreamer and *ObjectWriter typically cause a crash:

```
% cat c.c
int bar;
extern int foo __attribute__((alias("bar")));
% clang -c -fcommon c.c
fatal error: error in backend: Common symbol 'bar' cannot be used in assignment expr
PLEASE submit a bug report to ...
Stack dump:
...
```

`LLVMTargetMachine::addPassesToEmitFile` constructs `MachineModuleInfoWrapperPass`
which creates a MCContext without SourceMgr. `MCContext::reportError` calls
`report_fatal_error` which gets captured by Clang `LLVMErrorHandler` and gets translated
to the output above.

Since `MCContext::reportError` errors indicate user errors, such a crashing style error
is inappropriate. So this patch changes `report_fatal_error` to `SourceMgr().PrintMessage`.
```
% clang -c -fcommon c.c
<unknown>:0: error: Common symbol 'bar' cannot be used in assignment expr
```

Ideally we should at least recover the original filename (the line information
is generally lost). That requires general improvement to MC diagnostics,
because currently in many cases SMLoc information is lost.

show more ...


Revision tags: llvmorg-11.0.1, llvmorg-11.0.1-rc2
# 0a391060 04-Dec-2020 Derek Schuff <dschuff@chromium.org>

[WebAssembly] Add Object and ObjectWriter support for wasm COMDAT sections

Allow sections to be placed into COMDAT groups, in addtion to functions and data
segments.

Also make section symbols unnam

[WebAssembly] Add Object and ObjectWriter support for wasm COMDAT sections

Allow sections to be placed into COMDAT groups, in addtion to functions and data
segments.

Also make section symbols unnamed, which allows sections with identical names
(section names are independent of their section symbols, but previously we
gave the symbols the same name as their sections, which results in collisions
when sections are identically-named).

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

show more ...


Revision tags: llvmorg-11.0.1-rc1
# 42d21093 09-Nov-2020 jasonliu <jasonliu.development@gmail.com>

[XCOFF] Enable explicit sections on AIX

Implement mechanism to allow explicit sections to be generated on AIX.

Reviewed By: DiggerLin

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


Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2
# e9ac1495 11-Aug-2020 diggerlin <digger.llvm@gmail.com>

[AIX][XCOFF] change the operand of branch instruction from symbol name to qualified symbol name for function declarations

SUMMARY:

1. in the patch , remove setting storageclass in function .getXCO

[AIX][XCOFF] change the operand of branch instruction from symbol name to qualified symbol name for function declarations

SUMMARY:

1. in the patch , remove setting storageclass in function .getXCOFFSection and construct function of class MCSectionXCOFF
there are

XCOFF::StorageMappingClass MappingClass;
XCOFF::SymbolType Type;
XCOFF::StorageClass StorageClass;
in the MCSectionXCOFF class,
these attribute only used in the XCOFFObjectWriter, (asm path do not need the StorageClass)

we need get the value of StorageClass, Type,MappingClass before we invoke the getXCOFFSection every time.

actually , we can get the StorageClass of the MCSectionXCOFF from it's delegated symbol.

2. we also change the oprand of branch instruction from symbol name to qualify symbol name.
for example change
bl .foo
extern .foo
to
bl .foo[PR]
extern .foo[PR]

3. and if there is reference indirect call a function bar.
we also add
extern .bar[PR]

Reviewers: Jason liu, Xiangling Liao

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

show more ...


# 509f5c4e 29-Jul-2020 hgreving <hgreving@hendrik-laptop.lan>

[MC] Fix memory leak when allocating MCInst with bump allocator

Adds the function createMCInst() to MCContext that creates a MCInst using
a typed bump alloctor.

MCInst contains a SmallVector<MCOper

[MC] Fix memory leak when allocating MCInst with bump allocator

Adds the function createMCInst() to MCContext that creates a MCInst using
a typed bump alloctor.

MCInst contains a SmallVector<MCOperand, 8>. The SmallVector is POD only
for <= 8 operands. The default untyped bump pointer allocator of MCContext
does not delete the MCInst, so if the SmallVector grows, it's a leak.

This fixes https://bugs.llvm.org/show_bug.cgi?id=46900.

show more ...


Revision tags: llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3
# 6d3ae365 06-Jul-2020 jasonliu <jasonliu.development@gmail.com>

[XCOFF][AIX] Give symbol an internal name when desired symbol name contains invalid character(s)

Summary:

When a desired symbol name contains invalid character that the
system assembler could not p

[XCOFF][AIX] Give symbol an internal name when desired symbol name contains invalid character(s)

Summary:

When a desired symbol name contains invalid character that the
system assembler could not process, we need to emit .rename
directive in assembly path in order for that desired symbol name
to appear in the symbol table.

Reviewed By: hubert.reinterpretcast, DiggerLin, daltenty, Xiangling_L

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

show more ...


Revision tags: llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1
# 7a8edcb2 29-Apr-2020 Sylvain Audi <sylvain.audi@ubisoft.com>

[Clang] Restore replace_path_prefix instead of startswith

In D49466, sys::path::replace_path_prefix was used instead startswith for -f[macro/debug/file]-prefix-map options.
However those were revert

[Clang] Restore replace_path_prefix instead of startswith

In D49466, sys::path::replace_path_prefix was used instead startswith for -f[macro/debug/file]-prefix-map options.
However those were reverted later (commit rG3bb24bf25767ef5bbcef958b484e7a06d8689204) due to broken Windows tests.

This patch restores those replace_path_prefix calls.
It also modifies the prefix matching to be case-insensitive under Windows.

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

show more ...


# 86478d3d 16-Apr-2020 bd1976llvm <Ben.Dunbobbin@sony.com>

[MC][ELF] Put explicit section name symbols into entry size compatible sections

Ensure that symbols explicitly* assigned a section name are placed into
a section with a compatible entry size.

This

[MC][ELF] Put explicit section name symbols into entry size compatible sections

Ensure that symbols explicitly* assigned a section name are placed into
a section with a compatible entry size.

This is done by creating multiple sections with the same name** if
incompatible symbols are explicitly given the name of an incompatible
section, whilst:

- Avoiding using uniqued sections where possible (for readability and
to maximize compatibly with assemblers).

- Creating as few SHF_MERGE sections as possible (for efficiency).

Given that each symbol is assigned to a section in a single pass, we
must decide which section each symbol is assigned to without seeing the
properties of all symbols. A stable and easy to understand assignment is
desirable. The following rules facilitate this: The "generic" section
for a given section name will be mergeable if the name is a mergeable
"default" section name (such as .debug_str), a mergeable "implicit"
section name (such as .rodata.str2.2), or MC has already created a
mergeable "generic" section for the given section name (e.g. in response
to a section directive in inline assembly). Otherwise, the "generic"
section for a given name is non-mergeable; and, non-mergeable symbols
are assigned to the "generic" section, while mergeable symbols are
assigned to uniqued sections.

Terminology:
"default" sections are those always created by MC initially, e.g. .text
or .debug_str.

"implicit" sections are those created normally by MC in response to the
symbols that it encounters, i.e. in the absence of an explicit section
name assignment on the symbol, e.g. a function foo might be placed into
a .text.foo section.

"generic" sections are those that are referred to when a unique section
ID is not supplied, e.g. if there are multiple unique .bob sections then
".quad .bob" will reference the generic .bob section. Typically, the
generic section is just the first section of a given name to be created.
Default sections are always generic.

* Typically, section names might be explicitly assigned in source code
using a language extension e.g. a section attribute: _attribute_
((section ("section-name"))) -
https://clang.llvm.org/docs/AttributeReference.html

** I refer to such sections as unique/uniqued sections. In assembly the
", unique," assembly syntax is used to express such sections.

Fixes https://bugs.llvm.org/show_bug.cgi?id=43457.

See https://reviews.llvm.org/D68101 for previous discussions leading to
this patch.

Some minor fixes were required to LLVM's tests, for tests had been using
the old behavior - which allowed for explicitly assigning globals with
incompatible entry sizes to a section.

This fix relies on the ",unique ," assembly feature. This feature is not
available until bintuils version 2.35
(https://sourceware.org/bugzilla/show_bug.cgi?id=25380). If the
integrated assembler is not being used then we avoid using this feature
for compatibility and instead try to place mergeable symbols into
non-mergeable sections or issue an error otherwise.

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

show more ...


# 90a63f6d 15-Apr-2020 Fangrui Song <maskray@google.com>

[MC] Replace MCSection*::getName() with MCSection::getName(). NFC

I plan to use MCSection::getName() in D78138. Having the function in the base class is also convenient for debugging.

Reviewed By:

[MC] Replace MCSection*::getName() with MCSection::getName(). NFC

I plan to use MCSection::getName() in D78138. Having the function in the base class is also convenient for debugging.

Reviewed By: rnk

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

show more ...


# 7d1ff446 15-Apr-2020 Fangrui Song <maskray@google.com>

[MC] Rename MCSection*::getSectionName() to getName(). NFC

A pending change will merge MCSection*::getName() to MCSection::getName().


# 5be42f36 07-Apr-2020 Sam Clegg <sbc@chromium.org>

[WebAssembly][MC] Fix leak of std::string members in MCSymbolWasm

Summary: Fixes: https://bugs.llvm.org/show_bug.cgi?id=45452

Subscribers: dschuff, jgravelle-google, hiraditya, aheejin, sunfish, ll

[WebAssembly][MC] Fix leak of std::string members in MCSymbolWasm

Summary: Fixes: https://bugs.llvm.org/show_bug.cgi?id=45452

Subscribers: dschuff, jgravelle-google, hiraditya, aheejin, sunfish, llvm-commits

Tags: #llvm

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

show more ...


12345678910>>...15