Commit Graph

7 Commits

Author SHA1 Message Date
Rui Ueyama ac20c17962 MC/COFF: Do not emit forward associative section referenceds.
MSVC link.exe cannot handle associative sections that refer later
sections in the section header. Technically, such COFF object doesn't
violate the Microsoft COFF spec, as the spec doesn't say anything
about that, but still we should avoid doing that to make it compatible
with MS tools.

This patch assigns smaller section numbers to non-associative sections
and larger numbers to associative sections. This should resolve the
compatibility issue.

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

llvm-svn: 295464
2017-02-17 17:32:54 +00:00
David Majnemer c57d038240 MC: Fix associative sections on COFF
COFF sections in MC were represented by a tuple of section-name and
COMDAT-name.  This is not sufficient to represent a .text section
associated with another .text section; we need a way to distinguish
between the key section and the one marked associative.

llvm-svn: 211913
2014-06-27 17:19:44 +00:00
Saleem Abdulrasool e9bd916efe MC: prevent early DCE of empty sections
Prevent the early elimination of sections in the object writer.  There may be
references to the section itself by other symbols, which may potentially not be
possible to resolve.  ML (Visual Studio's Macro Assembler) also seems to retain
empty sections.

The elimination of symbols and sections which are unused should really occur at
the link phase.  This will not cause any change in the resulting binary, simply
in the generated object files.

The adjustments to the other unit tests account for the fluctuating section
index caused by the appearance of sections which were previously discarded.

llvm-svn: 210373
2014-06-06 21:40:16 +00:00
Rafael Espindola 0766ae08e5 Fix a few issues with comdat handling on COFF.
* Section association cannot use just the section name as many
sections can have the same name. With this patch, the comdat symbol in
an assoc section is interpreted to mean a symbol in the associated
section and the mapping is discovered from it.

* Comdat symbols were not being set correctly. Instead we were getting
whatever was output first for that section.

A consequence is that associative sections now must use .section to
set the association. Using .linkonce would not work since it is not
possible to change a sections comdat symbol (it is used to decide if
we should create a new section or reuse an existing one).

This includes r210298, which was reverted because it was asserting
on an associated section having the same comdat as the associated
section.

llvm-svn: 210367
2014-06-06 19:26:12 +00:00
Timur Iskhodzhanov 460cf8891b Revert r210298 'Correctly set the comdat symbol on COFF' as it asserts on Windows
llvm-svn: 210317
2014-06-06 08:18:18 +00:00
Rafael Espindola 942f4bc488 Correctly set the comdat symbol on COFF.
We extended the .section syntax to allow multiple sections with the
same name but different comdats, but currently we don't make sure that
the output section has that comdat symbol.

That happens to work with the code llc produces currently because it looks like

.section secName, "dr", one_only, "COMDATSym"
.globl COMDATSym
COMDATSym:
....

but that is not very friendly to anyone coding in assembly or even to
llc once we get comdat support in the IR.

This patch changes the coff object writer to make sure the comdat symbol is
output just after the section symbol, as required by the coff spec.

llvm-svn: 210298
2014-06-05 23:09:25 +00:00
Rafael Espindola 60ec3836a2 Support multiple COFF sections with the same name but different COMDAT.
This is the first step to fix pr17918.

It extends the .section directive a bit, inspired by what the ELF one looks
like. The problem with using linkonce is that given

.section foo
.linkonce....

.section foo
.linkonce

we would already have switched sections when getting to .linkonce. The cleanest
solution seems to be to add the comdat information in the .section itself.

llvm-svn: 195148
2013-11-19 19:52:52 +00:00