| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 231001
|
| |
|
|
|
|
| |
Otherwise we have to emit thread-safe initialization for them. NFC.
llvm-svn: 230894
|
| |
|
|
|
|
|
|
|
|
| |
This removes a bit of duplicated code and more importantly, remembers the
labels so that they don't need to be looked up by name.
This in turn allows for any name to be used and avoids a crash if the name
we wanted was already taken.
llvm-svn: 230772
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On 32bits x86 Darwin, the register mappings for the eh_frane and
debug_frame sections are different. Thus the same CFI instructions
should result in different registers in the object file. The
problem isn't target specific though, but it requires that the
mappings for EH register numbers be different from the standard
Dwarf one.
The patch looks a bit clumsy. LLVM uses the EH mapping as
canonical for everything frame related. Thus we need to do a
double conversion EH -> LLVM -> Non-EH, when emitting the
debug_frame section.
Fixes PR22363.
Differential Revision: http://reviews.llvm.org/D7593
llvm-svn: 230670
|
| |
|
|
| |
llvm-svn: 230479
|
| |
|
|
|
|
|
| |
The CodeView debug info section, .debug$S, also has this set. MinGW
sets this bit for their DWARF sections as well.
llvm-svn: 230156
|
| |
|
|
| |
llvm-svn: 230155
|
| |
|
|
|
|
|
| |
For compatiblity with GNU as. Binutils documents this as
'.uleb128 expressions'. Subtle, isn't it?
llvm-svn: 229911
|
| |
|
|
| |
llvm-svn: 229841
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously, subtarget features were a bitfield with the underlying type being uint64_t.
Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset.
No functional change.
Differential Revision: http://reviews.llvm.org/D7065
llvm-svn: 229831
|
| |
|
|
|
|
|
|
|
|
| |
Add support for having multiple sections with the same name and comdat.
Using this in combination with -ffunction-sections allows LLVM to output a .o
file with mulitple sections named .text. This saves space by avoiding long
unique names of the form .text.<C++ mangled name>.
llvm-svn: 229541
|
| |
|
|
|
|
|
|
|
|
| |
Original message:
Invert the section relocation map.
It now points from rel section to section. Use it to set sh_info, avoiding
a brittle name lookup.
llvm-svn: 229539
|
| |
|
|
|
|
|
|
| |
Original message:
Use the existing SymbolTableIndex instead of doing a lookup. NFC.
llvm-svn: 229538
|
| |
|
|
|
|
|
|
|
|
| |
Original message:
Create the Seciton -> Rel Section map when it is first needed. NFC.
Saves a walk over every section.
llvm-svn: 229536
|
| |
|
|
|
|
| |
requiring the macro. NFC; LLVM edition.
llvm-svn: 229340
|
| |
|
|
|
|
|
|
|
|
|
| |
Introduces a subset of C++14 integer sequences in STLExtras. This is
just enough to support unpacking a std::tuple into the arguments of
snprintf, we can add more of it when it's actually needed.
Also removes an ancient macro hack that leaks a macro into the global
namespace. Clean up users that made use of the convenient hack.
llvm-svn: 229337
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
regressions for LLDB on Linux. Rafael indicated on lldb-dev that we
should just go ahead and revert these but that he wasn't at a computer.
The patches backed out are as follows:
r228980: Add support for having multiple sections with the name and ...
r228889: Invert the section relocation map.
r228888: Use the existing SymbolTableIndex intsead of doing a lookup.
r228886: Create the Section -> Rel Section map when it is first needed.
These patches look pretty nice to me, so hoping its not too hard to get
them re-instated. =D
llvm-svn: 229080
|
| |
|
|
|
|
|
|
| |
Using this in combination with -ffunction-sections allows LLVM to output a .o
file with mulitple sections named .text. This saves space by avoiding long
unique names of the form .text.<C++ mangled name>.
llvm-svn: 228980
|
| |
|
|
|
|
| |
This should hopefully fix objc on AArch64.
llvm-svn: 228976
|
| |
|
|
|
|
|
| |
It now points from rel section to section. Use it to set sh_info, avoiding
a brittle name lookup.
llvm-svn: 228889
|
| |
|
|
| |
llvm-svn: 228888
|
| |
|
|
|
|
| |
Saves a walk over every section.
llvm-svn: 228886
|
| |
|
|
| |
llvm-svn: 228884
|
| |
|
|
|
|
| |
The next offset should be updated as well.
llvm-svn: 228883
|
| |
|
|
| |
llvm-svn: 228881
|
| |
|
|
| |
llvm-svn: 228879
|
| |
|
|
| |
llvm-svn: 228873
|
| |
|
|
|
|
|
|
|
|
| |
This allows IDEs to recognize the entire set of header files for
each of the core LLVM projects.
Differential Revision: http://reviews.llvm.org/D7526
Reviewed By: Chris Bieneman
llvm-svn: 228798
|
| |
|
|
|
|
| |
This fixes PR22060.
llvm-svn: 228565
|
| |
|
|
|
|
|
|
| |
COFF section flags are not idempotent:
'rd' will make a read-write section because 'd' implies write
'dr' will make a read-only section because 'r' disables write
llvm-svn: 228490
|
| |
|
|
| |
llvm-svn: 228256
|
| |
|
|
|
|
| |
Didn't see these calls in my release build locally when testing.
llvm-svn: 228254
|
| |
|
|
| |
llvm-svn: 228244
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Any code creating an MCSectionELF knows ELF and already provides the flags.
SectionKind is an abstraction used by common code that uses a plain
MCSection.
Use the flags to compute the SectionKind. This removes a lot of
guessing and boilerplate from the MCSectionELF construction.
llvm-svn: 227476
|
| |
|
|
| |
llvm-svn: 227101
|
| |
|
|
|
|
| |
This lets llvm-mc assemble files produced by gcc.
llvm-svn: 226895
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The ELF format is used on Windows by the MCJIT engine. Thus, on Windows, the
ELFObjectWriter can encounter symbols mangled using the MS Visual Studio C++
name mangling. Symbols mangled using the MSVC C++ name mangling can legally
have "@@@" as a substring. The EFLObjectWriter should not interpret the "@@@"
substring as specifying GNU-style symbol versioning. The ELFObjectWriter
therefore check for the MSVC C++ name mangling prefix which is either "?", "@?",
"imp_?" or "imp_?@".
llvm-svn: 226830
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Windows supports a restricted set of relocations (compared to ARM ELF). In some
cases, we may end up generating an unsupported relocation. This can occur with
bad input to the assembler in particular (the frontend should never generate
code that cannot be compiled). Generate an error rather than just aborting.
The change in the API is driven by the desire to provide a slightly more helpful
message for debugging purposes.
llvm-svn: 226779
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fixes are to note that AArch64 has additional restrictions on when local
relocations can be used. In particular, ld64 requires that relocations to
cstring/cfstrings use linker visible symbols.
Original message:
In an assembly expression like
bar:
.long L0 + 1
the intended semantics is that bar will contain a pointer one byte past L0.
In sections that are merged by content (strings, 4 byte constants, etc), a
single position in the section doesn't give the linker enough information.
For example, it would not be able to tell a relocation must point to the
end of a string, since that would look just like the start of the next.
The solution used in ELF to use relocation with symbols if there is a non-zero
addend.
In MachO before this patch we would just keep all symbols in some sections.
This would miss some cases (only cstrings on x86_64 were implemented) and was
inefficient since most relocations have an addend of 0 and can be represented
without the symbol.
This patch implements the non-zero addend logic for MachO too.
llvm-svn: 226503
|
| |
|
|
|
|
|
|
|
|
|
| |
An assignment will produce a symbol with a given section and offset. There is
no way to represent something like "1 byte after a common symbol".
This matches the behavior of GNU as.
Part of PR22217.
llvm-svn: 226470
|
| |
|
|
| |
llvm-svn: 226416
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch was generated by a clang tidy checker that is being open sourced.
The documentation of that checker is the following:
/// The emptiness of a container should be checked using the empty method
/// instead of the size method. It is not guaranteed that size is a
/// constant-time function, and it is generally more efficient and also shows
/// clearer intent to use empty. Furthermore some containers may implement the
/// empty method but not implement the size method. Using empty whenever
/// possible makes it easier to switch to another container in the future.
Patch by Gábor Horváth!
llvm-svn: 226161
|
| |
|
|
|
|
| |
This reverts commit r225644 while I debug a regression.
llvm-svn: 226022
|
| |
|
|
|
|
|
|
|
|
|
| |
utils/sort_includes.py.
I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the InstrProf library that I've
added. No functionality changed here, just mechanical cleanup of the
include order.
llvm-svn: 225974
|
| |
|
|
|
|
| |
the TargetMachine level and the MC level.
llvm-svn: 225891
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These intrinsics allow multiple functions to share a single stack
allocation from one function's call frame. The function with the
allocation may only perform one allocation, and it must be in the entry
block.
Functions accessing the allocation call llvm.recoverframeallocation with
the function whose frame they are accessing and a frame pointer from an
active call frame of that function.
These intrinsics are very difficult to inline correctly, so the
intention is that they be introduced rarely, or at least very late
during EH preparation.
Reviewers: echristo, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D6493
llvm-svn: 225746
|
| |
|
|
| |
llvm-svn: 225740
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One is that AArch64 has additional restrictions on when local relocations can
be used. We have to take those into consideration when deciding to put a L
symbol in the symbol table or not.
The other is that ld64 requires the relocations to cstring to use linker
visible symbols on AArch64.
Thanks to Michael Zolotukhin for testing this!
Remove doesSectionRequireSymbols.
In an assembly expression like
bar:
.long L0 + 1
the intended semantics is that bar will contain a pointer one byte past L0.
In sections that are merged by content (strings, 4 byte constants, etc), a
single position in the section doesn't give the linker enough information.
For example, it would not be able to tell a relocation must point to the
end of a string, since that would look just like the start of the next.
The solution used in ELF to use relocation with symbols if there is a non-zero
addend.
In MachO before this patch we would just keep all symbols in some sections.
This would miss some cases (only cstrings on x86_64 were implemented) and was
inefficient since most relocations have an addend of 0 and can be represented
without the symbol.
This patch implements the non-zero addend logic for MachO too.
llvm-svn: 225644
|
| |
|
|
|
|
|
|
| |
This adds support for parsing and emitting the SBREL relocation variant for the
ARM target. Handling this relocation variant is necessary for supporting the
full ARM ELF specification. Addresses PR22128.
llvm-svn: 225595
|
| |
|
|
|
|
|
|
|
|
| |
introduced.
A test case for the bug was already committed in r225385.
Patch by Rafael Espindola.
llvm-svn: 225534
|