DWARF5 spec says about single file split case:
"The sections that do not require relocation, however, can be written
to the relocatable object (.o) file but ignored by the
the linker or they can be written to a separate DWARF object (.dwo) file
that need not be accessed by the linker."
Nice way to make linker to ignore them is to set SHF_EXCLUDE flag.
It seems to be not harmful to always set it for .dwo sections.
That is what this patch does.
Differential revision: https://reviews.llvm.org/D52303
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@342800 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The TType encoding, LSDA encoding, and personality encoding are all
passed explicitly by CodeGen to the assembler through .cfi_* directives,
so only the AsmPrinter needs to know about them.
The FDE CFI encoding however, controls the encoding of the label
implicitly created by the .cfi_startproc directive. That directive seems
to be special in that it doesn't take an encoding, so the assembler just
has to know how to encode one DSO-local label reference from .eh_frame
to .text.
As a result, it looks like MC will continue to have to know when the
large code model is in use. Perhaps we could invent a '.cfi_startproc
[large]' flag so that this knowledge doesn't need to pollute the
assembler.
Reviewers: davide, lliu0, JDevlieghere
Subscribers: hiraditya, fedor.sergeev, llvm-commits
Differential Revision: https://reviews.llvm.org/D50533
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@339397 91177308-0d34-0410-b5e6-96231b3b80d8
Getting the DWARF types section is only implemented for ELF object
files. We already disabled emitting debug types in clang (r337717), but
now we also report an fatal error (rather than crashing) when trying to
obtain this section in MC. Additionally we ignore the generate debug
types flag for unsupported target triples.
See PR38190 for more information.
Differential revision: https://reviews.llvm.org/D50057
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338527 91177308-0d34-0410-b5e6-96231b3b80d8
There are quite a few if statements that enumerate all these cases. It gets
even worse in our fork of LLVM where we also have a Triple::cheri (which
is mips64 + CHERI instructions) and we had to update all if statements that
check for Triple::mips64 to also handle Triple::cheri. This patch helps to
reduce our diff to upstream and should also make some checks more readable.
Reviewed By: atanasyan
Differential Revision: https://reviews.llvm.org/D48548
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335493 91177308-0d34-0410-b5e6-96231b3b80d8
With compilation fix.
Original commit message:
D39788 added a '.stack-size' section containing metadata on function stack sizes
to output ELF files behind the new -stack-size-section flag.
This change does following two things on top:
1) Imagine the case when there are -ffunction-sections flag given and there are text sections in COMDATs.
The patch adds a '.stack-size' section into corresponding COMDAT group, so that linker will be able to
eliminate them fast during resolving the COMDATs.
2) Patch sets a SHF_LINK_ORDER flag and links '.stack-size' with the corresponding .text.
With that linker will be able to do -gc-sections on dead stack sizes sections.
Differential revision: https://reviews.llvm.org/D46874
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335336 91177308-0d34-0410-b5e6-96231b3b80d8
D39788 added a '.stack-size' section containing metadata on function stack sizes
to output ELF files behind the new -stack-size-section flag.
This change does following two things on top:
1) Imagine the case when there are -ffunction-sections flag given and there are text sections in COMDATs.
The patch adds a '.stack-size' section into corresponding COMDAT group, so that linker will be able to
eliminate them fast during resolving the COMDATs.
2) Patch sets a SHF_LINK_ORDER flag and links '.stack-size' with the corresponding .text.
With that linker will be able to do -gc-sections on dead stack sizes sections.
Differential revision: https://reviews.llvm.org/D46874
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335332 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Darwin dynamic linker can handle weak symbols in ConstDataSection.
ReadonReadOnlyWithRel symbols should be emitted in ConstDataSection
instead of normal DataSection.
rdar://problem/39298457
Reviewers: dexonsmith, kledzik
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D45472
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@329752 91177308-0d34-0410-b5e6-96231b3b80d8
- MSVC was not OK with a static_assert referencing a non-static member
variable, even though it was just in a sizeof(expression). I move the
assert into the emit function, where it is probably more useful.
- Tests were failing in builds which did not have the X86 target
configured. Since this functionality is not target-specific, I have
removed the target specifiers from the .ll files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@329201 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch adds a DwarfAccelTableEmitter class, which generates an
accelerator table, as specified in DWARF v5 standard. At the moment it
only generates a DIE offset column and (if we are indexing more than one
compile unit) a CU column.
Indexing type units is not currently supported, as we don't even have
the ability to generate DWARF v5-compatible compile units.
The implementation is not data-source agnostic like the one generating
apple tables. This was not necessary as we currently only have one user
of this code, and without a second user it was not obvious to me how to
best abstract this. (The difference between these tables and the apple
ones is that they need a lot more metadata about the debug info they are
indexing).
The generation is triggered by the --accel-tables argument, which
supersedes the --dwarf-accel-tables arg -- the latter was a simple
on-off switch, but not we can choose between two kinds of accelerator
tables we can generate.
This is tested by parsing the generated tables with llvm-dwarfdump and
the DWARFVerifier, and I've also checked that GNU readelf is able to
make sense of the tables.
Differential Revision: https://reviews.llvm.org/D43286
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@329179 91177308-0d34-0410-b5e6-96231b3b80d8
offsets for code models other than small/medium. For JIT application,
memory layout is less controlled and can result in truncations
otherwise.
Patch based on one by Olexa Bilaniuk!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328400 91177308-0d34-0410-b5e6-96231b3b80d8
Adds option /guard:cf to clang-cl and -cfguard to cc1 to emit function IDs
of functions that have their address taken into a section named .gfids$y for
compatibility with Microsoft's Control Flow Guard feature.
The original patch didn't have the lit.local.cfg file that restricts the new
test to x86, thus the new test was failing on the non-x86 bots.
Differential Revision: https://reviews.llvm.org/D40531
The reverts r322008, which was a revert of r322005.
This reverts commit a05b89f9aca70597dc79fe97bc49b50b51f525ba.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322136 91177308-0d34-0410-b5e6-96231b3b80d8
Adds option /guard:cf to clang-cl and -cfguard to cc1 to emit function IDs
of functions that have their address taken into a section named .gfids$y for
compatibility with Microsoft's Control Flow Guard feature.
Differential Revision: https://reviews.llvm.org/D40531
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322005 91177308-0d34-0410-b5e6-96231b3b80d8
Currently this is an LLVM extension to the COFF spec which is
experimental and intended to speed up linking. For now it is
behind a hidden cl::opt flag, but in the future we can move it
to a "real" cc1 flag and have the driver pass it through whenever
it is appropriate.
The patch to actually make use of this section in lld will come
in a followup.
Differential Revision: https://reviews.llvm.org/D40917
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320649 91177308-0d34-0410-b5e6-96231b3b80d8
Re applying after fixing issues in the diff, sorry for any painful conflicts/merges!
Original RFC: http://lists.llvm.org/pipermail/llvm-dev/2017-August/117028.html
This change adds a '.stack-size' section containing metadata on function stack sizes to output ELF files behind the new -stack-size-section flag. The section contains pairs of function symbol references (8 byte) and stack sizes (unsigned LEB128).
The contents of this section can be used to measure changes to stack sizes between different versions of the compiler or a source base. The advantage of having a section is that we can extract this information when examining binaries that we didn't build, and it allows users and tools easy access to that information just by referencing the binary.
There is a follow up change to add an option to clang.
Thanks.
Reviewers: hfinkel, MatzeB
Reviewed By: MatzeB
Subscribers: thegameg, asb, llvm-commits
Differential Revision: https://reviews.llvm.org/D39788
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319430 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Original RFC: http://lists.llvm.org/pipermail/llvm-dev/2017-August/117028.html
I wasn't sure who to put as reviewers, so please add/remove people as appropriate.
This change adds a '.stack-size' section containing metadata on function stack sizes to output ELF files behind the new -stack-size-section flag. The section contains pairs of function symbol references (8 byte) and stack sizes (unsigned LEB128).
The contents of this section can be used to measure changes to stack sizes between different versions of the compiler or a source base. The advantage of having a section is that we can extract this information when examining binaries that we didn't build, and it allows users and tools easy access to that information just by referencing the binary.
There is a follow up change to add an option to clang.
Thanks.
Reviewers: hfinkel, MatzeB
Reviewed By: MatzeB
Subscribers: thegameg, asb, llvm-commits
Differential Revision: https://reviews.llvm.org/D39788
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319423 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Xcode's dsymutil emits a __swift_ast DWARF section, which is required for debugging,
and which contains a byte-for-byte dump of the swiftmodule file.
Add this feature to llvm-dsymutil.
Tested with `gobjdump --dwarf=info -s`, by verifying that the contents of
`__DWARF.__swift_ast` match between Xcode's dsymutil and llvm-dsymutil
(Xcode's dwarfdump and llvm-dwarfdump don't currently recognize the
__swift_ast section).
Reviewers: aprantl, friss
Subscribers: llvm-commits, JDevlieghere
Differential Revision: https://reviews.llvm.org/D38504
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315066 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Xcode's dsymutil emits a __swift_ast DWARF section, which is required for debugging,
and which contains a byte-for-byte dump of the swiftmodule file.
Add this feature to llvm-dsymutil.
Tested with `gobjdump --dwarf=info -s`, by verifying that the contents of
`__DWARF.__swift_ast` match between Xcode's dsymutil and llvm-dsymutil
(Xcode's dwarfdump and llvm-dwarfdump don't currently recognize the
__swift_ast section).
Reviewers: aprantl, friss
Subscribers: llvm-commits, JDevlieghere
Differential Revision: https://reviews.llvm.org/D38504
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315014 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Xcode's dsymutil emits a __swift_ast DWARF section, which is required for debugging,
and which contains a byte-for-byte dump of the swiftmodule file.
Add this feature to llvm-dsymutil.
Tested with `gobjdump --dwarf=info -s`, by verifying that the contents of
`__DWARF.__swift_ast` match between Xcode's dsymutil and llvm-dsymutil
(Xcode's dwarfdump and llvm-dwarfdump don't currently recognize the
__swift_ast section).
Reviewers: aprantl, friss
Subscribers: llvm-commits, JDevlieghere
Differential Revision: https://reviews.llvm.org/D38504
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315004 91177308-0d34-0410-b5e6-96231b3b80d8
I was surprised to see the code model being passed to MC. After all,
it assembles code, it doesn't create it.
The one place it is used is in the expansion of .cfi directives to
handle .eh_frame being more that 2gb away from the code.
As far as I can tell, gnu assembler doesn't even have an option to
enable this. Compiling a c file with gcc -mcmodel=large produces a
regular looking .eh_frame. This is probably because in practice linker
parse and recreate .eh_frames.
In llvm this is used because the JIT can place the code and .eh_frame
very far apart. Ideally we would fix the jit and delete this
option. This is hard.
Apart from confusion another problem with the current interface is
that most callers pass CodeModel::Default, which is bad since MC has
no way to map it to the target default if it actually needed to.
This patch then replaces the argument with a boolean with a default
value. The vast majority of users don't ever need to look at it. In
fact, only CodeGen and llvm-mc use it and llvm-mc just to enable more
testing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@309884 91177308-0d34-0410-b5e6-96231b3b80d8
This creates a new library called BinaryFormat that has all of
the headers from llvm/Support containing structure and layout
definitions for various types of binary formats like dwarf, coff,
elf, etc as well as the code for identifying a file from its
magic.
Differential Revision: https://reviews.llvm.org/D33843
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304864 91177308-0d34-0410-b5e6-96231b3b80d8
. there should be no runtime relocation inside the bpf function.
. relocation supported here mostly for debugging.
. a test case is added.
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302055 91177308-0d34-0410-b5e6-96231b3b80d8
All MIPS .debug_* sections should be marked with ELF type SHT_MIPS_DWARF
accordingly the specification [1]. Also the same section type is assigned
to these sections by GNU tools.
[1] ftp.software.ibm.com/software/os390/czos/dwarf/mips_extensions.pdf
Differential Revision: https://reviews.llvm.org/D29789
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297447 91177308-0d34-0410-b5e6-96231b3b80d8
With the "wasm32-unknown-unknown-wasm" triple, this allows writing out
simple wasm object files, and is another step in a larger series toward
migrating from ELF to general wasm object support. Note that this code
and the binary format itself is still experimental.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296190 91177308-0d34-0410-b5e6-96231b3b80d8
On ELF every section can have a corresponding section symbol. When in
an assembly file we have
.quad .text
the '.text' refers to that symbol.
The way we used to handle them is to leave .text an undefined symbol
until the very end when the object writer would map them to the
actual section symbol.
The problem with that is that anything before the end would see an
undefined symbol. This could result in bad diagnostics
(test/MC/AArch64/label-arithmetic-diags-elf.s), or incorrect results
when using the asm streamer (est/MC/Mips/expansion-jal-sym-pic.s).
Fixing this will also allow using the section symbol earlier for
setting sh_link of SHF_METADATA sections.
This patch includes a few hacks to avoid changing our behaviour when
handling conflicts between section symbols and other symbols. I
reported pr31850 to track that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293936 91177308-0d34-0410-b5e6-96231b3b80d8
The main issue here is that the "thumb" flag wasn't set for some of these
sections, making MSVC's link.exe fails to correctly relocate code
against the symbols inside these sections. link.exe could fail for
instance with the "fixup is not aligned for target 'XX'" error. If
linking doesn't fail, the relocation process goes wrong in the end and
invalid code is generated by the linker.
This patch adds Thumb/ARM information so that the right flags are set
on COFF/Windows.
Patch by Adrien Guinet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273880 91177308-0d34-0410-b5e6-96231b3b80d8
MC only needs to know if the output is PIC or not. It never has to
decide about creating GOTs and PLTs for example. The only thing that
MC itself uses this information for is expanding "macros" in sparc and
mips. The rest I am pretty sure could be moved to CodeGen.
This is a cleanup and isolates the code from future changes to
Reloc::Model.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269909 91177308-0d34-0410-b5e6-96231b3b80d8
