Stop creating covmap as note section on ELF

covmap needs to created as non allocatable, but not with
SHT_NOTE. The latter was needed to workaround a problem
of BFD linker with gc, which is no longer

Stop creating covmap as note section on ELF

covmap needs to created as non allocatable, but not with
SHT_NOTE. The latter was needed to workaround a problem
of BFD linker with gc, which is no longer needed. (A more
proper longer term fix requires changing FE driver to force
referencing the section using linker script).

Differential Revision: http://reviews.llvm.org/D17309

llvm-svn: 261228

show more ...

[Objective-C] Support a new special module flag.

"Objective-C Class Properties" will be put into the objc_imageinfo struct.

rdar://23891898

llvm-svn: 259270

[PGO] [Coverage] put covmap into note section with no 'alloc flag' (Linux)

Coverage mapping data is not referenced by runtime, and they won't be dumped
into profile data. There is no need to allocat

[PGO] [Coverage] put covmap into note section with no 'alloc flag' (Linux)

Coverage mapping data is not referenced by runtime, and they won't be dumped
into profile data. There is no need to allocate memory for covmap sections.
A good side effect of this change is that the coverage map data won't be mistakenly
garbage collected by the linker (for Gold linker only, BFD linker has an issue where the a bug is filed).
Tested with clang build with instrumentation and -fcoverage-mapping and linker GC. The size of
covmap section is ~17.6M so the text segment size will be reduced by this amount with this change.

llvm-svn: 257781

show more ...

Stop producing .data.rel sections.

If a section is rw, it is irrelevant if the dynamic linker will write to
it or not.

It looks like llvm implemented this because gcc was doing it. It looks
like gc

Stop producing .data.rel sections.

If a section is rw, it is irrelevant if the dynamic linker will write to
it or not.

It looks like llvm implemented this because gcc was doing it. It looks
like gcc implemented this in the hope that it would put all the
relocated items close together and speed up the dynamic linker.

There are two problem with this:
* It doesn't work. Both bfd and gold will map .data.rel to .data and
concatenate the input sections in the order they are seen.
* If we want a feature like that, it can be implemented directly in the
linker since it knowns where the dynamic relocations are.

llvm-svn: 253436

show more ...

Drop prelink support.

The way prelink used to work was

* The compiler decides if a given section only has relocations that
are know to point to the same DSO. If so, it names it
.data.rel.ro.local<s

Drop prelink support.

The way prelink used to work was

* The compiler decides if a given section only has relocations that
are know to point to the same DSO. If so, it names it
.data.rel.ro.local<something>.
* The static linker puts all of these together.
* The prelinker program assigns addresses to each library and resolves
the local relocations.

There are many problems with this:
* It is incompatible with address space randomization.
* The information passed by the compiler is redundant. The linker
knows if a given relocation is in the same DSO or not. If could sort
by that if so desired.
* There are newer ways of speeding up DSO (gnu hash for example).
* Even if we want to implement this again in the compiler, the previous
implementation is pretty broken. It talks about relocations that are
"resolved by the static linker". If they are resolved, there are none
left for the prelinker. What one needs to track is if an expression
will require only dynamic relocations that point to the same DSO.

At this point it looks like the prelinker is an historical curiosity.
For example, fedora has retired it because it failed to build for two
releases
(http://pkgs.fedoraproject.org/cgit/prelink.git/commit/?id=eb43100a8331d91c801ee3dcdb0a0bb9babfdc1f)

This patch removes support for it. That is, it stops printing the
".local" sections.

llvm-svn: 253280

show more ...

CodeGen, Target: Move Mach-O-specific symbol name logic to Mach-O lowering.

A profile of an LTO link of Chrome revealed that we were spending some
~30-50% of execution time in the function Constant:

CodeGen, Target: Move Mach-O-specific symbol name logic to Mach-O lowering.

A profile of an LTO link of Chrome revealed that we were spending some
~30-50% of execution time in the function Constant::getRelocationInfo(),
which is called from TargetLoweringObjectFile::getKindForGlobal() and in turn
from TargetMachine::getNameWithPrefix().

It turns out that we only need the result of getKindForGlobal() when
targeting Mach-O, so this change moves the relevant part of the logic to
TargetLoweringObjectFileMachO.

NFCI.

Differential Revision: http://reviews.llvm.org/D14168

llvm-svn: 252014

show more ...

Sink COFF.h MC include into .cpp files

This prevents MC clients from getting COFF.h, which conflicts with
winnt.h macros. Also a minor IWYU cleanup. Now the only public headers
including COFF.h are

Sink COFF.h MC include into .cpp files

This prevents MC clients from getting COFF.h, which conflicts with
winnt.h macros. Also a minor IWYU cleanup. Now the only public headers
including COFF.h are in Object, and they actually need it.

llvm-svn: 246784

show more ...

Fix some comment typos.

llvm-svn: 244402

Remove DataLayout from TargetLoweringObjectFile, redirect to Module

Summary:
This change is part of a series of commits dedicated to have a single
DataLayout during compilation by using always the o

Remove DataLayout from TargetLoweringObjectFile, redirect to Module

Summary:
This change is part of a series of commits dedicated to have a single
DataLayout during compilation by using always the one owned by the
module.

Reviewers: echristo

Subscribers: yaron.keren, rafael, llvm-commits, jholewinski

Differential Revision: http://reviews.llvm.org/D11079

From: Mehdi Amini <[email protected]>
llvm-svn: 242385

show more ...

COFF: Do not assign linker-weak symbols to selectany comdat sections.

It is mandatory to specify a comdat in order to receive comdat semantics
for a symbol. We were previously getting this wrong in

COFF: Do not assign linker-weak symbols to selectany comdat sections.

It is mandatory to specify a comdat in order to receive comdat semantics
for a symbol. We were previously getting this wrong in -function-sections
mode; linker-weak symbols were being emitted in a selectany comdat. This
change causes such symbols to use a noduplicates comdat instead, fixing
the inconsistency.

Also correct an inaccuracy in the docs.

Differential Revision: http://reviews.llvm.org/D10828

llvm-svn: 241103

show more ...

Teach LTOModule to emit linker flags for dllexported symbols, plus interface cleanup.

This change unifies how LTOModule and the backend obtain linker flags
for globals: via a new TargetLoweringObjec

Teach LTOModule to emit linker flags for dllexported symbols, plus interface cleanup.

This change unifies how LTOModule and the backend obtain linker flags
for globals: via a new TargetLoweringObjectFile member function named
emitLinkerFlagsForGlobal. A new function LTOModule::getLinkerOpts() returns
the list of linker flags as a single concatenated string.

This change affects the C libLTO API: the function lto_module_get_*deplibs now
exposes an empty list, and lto_module_get_*linkeropts exposes a single element
which combines the contents of all observed flags. libLTO should never have
tried to parse the linker flags; it is the linker's job to do so. Because
linkers will need to be able to parse flags in regular object files, it
makes little sense for libLTO to have a redundant mechanism for doing so.

The new API is compatible with the old one. It is valid for a user to specify
multiple linker flags in a single pragma directive like this:

#pragma comment(linker, "/defaultlib:foo /defaultlib:bar")

The previous implementation would not have exposed
either flag via lto_module_get_*deplibs (as the test in
TargetLoweringObjectFileCOFF::getDepLibFromLinkerOpt was case sensitive)
and would have exposed "/defaultlib:foo /defaultlib:bar" as a single flag via
lto_module_get_*linkeropts. This may have been a bug in the implementation,
but it does give us a chance to fix the interface.

Differential Revision: http://reviews.llvm.org/D10548

llvm-svn: 241010

show more ...

Create a MCSymbolELF.

This create a MCSymbolELF class and moves SymbolSize since only ELF
needs a size expression.

This reduces the size of MCSymbol from 56 to 48 bytes.

llvm-svn: 238801

MC: Clean up MCExpr naming. NFC.

llvm-svn: 238634

Move alignment from MCSectionData to MCSection.

This starts merging MCSection and MCSectionData.

There are a few issues with the current split between MCSection and
MCSectionData.

* It optimizes t

Move alignment from MCSectionData to MCSection.

This starts merging MCSection and MCSectionData.

There are a few issues with the current split between MCSection and
MCSectionData.

* It optimizes the the not as important case. We want the production
of .o files to be really fast, but the split puts the information used
for .o emission in a separate data structure.

* The ELF/COFF/MachO hierarchy is not represented in MCSectionData,
leading to some ad-hoc ways to represent the various flags.

* It makes it harder to remember where each item is.

The attached patch starts merging the two by moving the alignment from
MCSectionData to MCSection.

Most of the patch is actually just dropping 'const', since
MCSectionData is mutable, but MCSection was not.

llvm-svn: 237936

show more ...

MC: Clean up method names in MCContext.

The naming was a mish-mash of old and new style. Update to be consistent
with the new. NFC.

llvm-svn: 237594

Implement unique sections with an unique ID.

This allows the compiler/assembly programmer to switch back to a
section. This in turn fixes the bootstrap failure on powerpc (tested
on gcc110) without

Implement unique sections with an unique ID.

This allows the compiler/assembly programmer to switch back to a
section. This in turn fixes the bootstrap failure on powerpc (tested
on gcc110) without changing the ppc codegen at all.

I will try to cleanup the various getELFSection overloads in a followup patch.
Just using a default argument now would lead to ambiguities.

llvm-svn: 234099

show more ...

COFF: Let globals with private linkage reside in their own section

COFF COMDATs (for selection kinds other than 'select any') require at
least one non-section symbol in the symbol table.
Satisfy thi

COFF: Let globals with private linkage reside in their own section

COFF COMDATs (for selection kinds other than 'select any') require at
least one non-section symbol in the symbol table.
Satisfy this by morally enhancing the linkage from private to internal.

Differential Revision: http://reviews.llvm.org/D8394

llvm-svn: 232570

show more ...

Revert "COFF: Let globals with private linkage reside in their own section"

This reverts commit r232539. This was committed accidently.

llvm-svn: 232543

Revert "Address review comments"

This reverts commit r232540. This was committed accidently.

llvm-svn: 232541

Address review comments

llvm-svn: 232540

COFF: Let globals with private linkage reside in their own section

Summary:
COFF COMDATs (for selection kinds other than 'select any') require at
least one non-section symbol in the symbol table.
Sa

COFF: Let globals with private linkage reside in their own section

Summary:
COFF COMDATs (for selection kinds other than 'select any') require at
least one non-section symbol in the symbol table.
Satisfy this by morally enhancing the linkage from private to internal.

Reviewers: rafael

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D8374

llvm-svn: 232539

show more ...

Put jump tables in unique sections on COFF.

If a function is going in an unique section (because of -ffunction-sections
for example), putting a jump table in .rodata will keep .rodata alive and
that

Put jump tables in unique sections on COFF.

If a function is going in an unique section (because of -ffunction-sections
for example), putting a jump table in .rodata will keep .rodata alive and
that will keep alive any other function that also has a jump table.

Instead, put the jump table in a unique section that is associated with the
function.

llvm-svn: 231961

show more ...

[AsmPrinter][TLOF] 32-bit MachO support for replacing GOT equivalents

Add MachO 32-bit (i.e. arm and x86) support for replacing global GOT equivalent
symbol accesses. Unlike 64-bit targets, there's

[AsmPrinter][TLOF] 32-bit MachO support for replacing GOT equivalents

Add MachO 32-bit (i.e. arm and x86) support for replacing global GOT equivalent
symbol accesses. Unlike 64-bit targets, there's no GOTPCREL relocation, and
access through a non_lazy_symbol_pointers section is used instead.

-- before

_extgotequiv:
.long _extfoo

_delta:
.long _extgotequiv-_delta

-- after

_delta:
.long L_extfoo$non_lazy_ptr-_delta

.section __IMPORT,__pointers,non_lazy_symbol_pointers
L_extfoo$non_lazy_ptr:
.indirect_symbol _extfoo
.long 0

llvm-svn: 231475

show more ...

Put jump tables in distinct sections if -ffunction-sections is used.

A small regression in r230411 was that we were basing the decision on
-fdata-sections.

llvm-svn: 230707

Support SHF_MERGE sections in COMDATs.

This patch unifies the comdat and non-comdat code paths. By doing this
it add missing features to the comdat side and removes the fixed
section assumptions fro

Support SHF_MERGE sections in COMDATs.

This patch unifies the comdat and non-comdat code paths. By doing this
it add missing features to the comdat side and removes the fixed
section assumptions from the non-comdat side.

In ELF there is no one true section for "4 byte mergeable" constants.
We are better off computing the required properties of the section
and asking the context for it.

llvm-svn: 230411

show more ...