--
This patch enables LLVM to emit Win64-native unwind info rather than
DWARF CFI. It handles all corner cases (I hope), including stack
realignment.
Because the unwind info is not flexible enough to describe stack frames
with a gap of unknown size in the middle, such as the one caused by
stack realignment, I modified register spilling code to place all spills
into the fixed frame slots, so that they can be accessed relative to the
frame pointer.
Patch by Vadim Chugunov!
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D4081
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211691 91177308-0d34-0410-b5e6-96231b3b80d8
In assembly the expression a=b is parsed as an assignment, so it should be
printed as one.
This remove a truly horrible hack for producing a label with "a=.". It would
be used by codegen but would never be reached by the asm parser. Sorry I
missed this when it was first committed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211639 91177308-0d34-0410-b5e6-96231b3b80d8
"Fix PR20056: Implement pseudo LDR <reg>, =<literal/label> for AArch64"
Missed files are added in this commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211605 91177308-0d34-0410-b5e6-96231b3b80d8
This patch is based on the changes from ARM target [1,2]
Based on ARM doc [3], if the literal value can be loaded with a valid MOV,
it can emit that instruction. This is implemented in this patch.
[1] Fix PR18345: ldr= pseudo instruction produces incorrect code when using in inline assembly
Author: David Peixotto <dpeixott@codeaurora.org>
commit b92cca2228 (r200777)
[2] Implement the ldr-pseudo opcode for ARM assembly
Author: David Peixotto <dpeixott@codeaurora.org>
commit 0fa193b086 (r197708)
[3] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0802a/CJAHAIBC.html
Differential Revision: http://reviews.llvm.org/D4163
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211533 91177308-0d34-0410-b5e6-96231b3b80d8
Correct the section flags for code built for Windows on ARM with
`-ffunction-sections`. Windows on ARM uses solely Thumb-2 instructions, and
indicates that the function is thumb by placing it in a text section that has
IMAGE_SCN_MEM_16BIT flag set.
When we encounter a .section directive, a new section is constructed. This may
be a text segment. In order to identify that we need the additional flag,
expose the target triple through the ObjectFileInfo as this information is lost
otherwise.
Since any modern ARM targeting environment on Windows would be Thumb-2 (Windows
ARM NT or Windows Embedded Compact), introducing a new flag to indicate the
section attribute seems to be a bit overkill. Simply depend on the target
triple. Since there is one location that this information is currently needed,
creating a target specific assembly parser and delegating the parsing of section
switches also feels a bit heavy handed. If it turns out that this information
ends up changing additional behaviour, then it may be worth considering that
alternative.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211481 91177308-0d34-0410-b5e6-96231b3b80d8
This patch enables LLVM to emit Win64-native unwind info rather than
DWARF CFI. It handles all corner cases (I hope), including stack
realignment.
Because the unwind info is not flexible enough to describe stack frames
with a gap of unknown size in the middle, such as the one caused by
stack realignment, I modified register spilling code to place all spills
into the fixed frame slots, so that they can be accessed relative to the
frame pointer.
Patch by Vadim Chugunov!
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D4081
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211399 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, when using llvm as an assembler, DWARF debug information is only
generated for the .text section. This patch modifies this so that DWARF info
is emitted for all executable sections.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211273 91177308-0d34-0410-b5e6-96231b3b80d8
used by all of the MC level tools and codegen. Fix up all uses
in the compiler to use this and set it on the context accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211257 91177308-0d34-0410-b5e6-96231b3b80d8
ARMTargetStreamer implements ConstantPool and AssmeblerConstantPools
to keep track of assembler-generated constant pools that are used for
ldr-pseudo.
When implementing ldr-pseudo for AArch64, these two classes can be reused.
So this patch factors them out from ARM target to the general MC lib.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211198 91177308-0d34-0410-b5e6-96231b3b80d8
Most Windows platforms use auxiliary data for unwinding. This information is
stored in the .pdata section. The encoding format for the data differs between
architectures and Windows variants. Windows MIPS and Alpha use identical
formats; Alpha64 is the same with different widths. Windows x86_64 and Itanium
share the representation. All Windows CE entries are identical irrespective of
the architecture. ARMv7 (Windows [NT] on ARM) has its own format.
This enumeration will become the differentiator once the windows EH emission
infrastructure is generalised, allowing us to emit the necessary unwinding
information for Windows on ARM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210634 91177308-0d34-0410-b5e6-96231b3b80d8
I saw at least a memory leak or two from inspection (on probably
untested error paths) and r206991, which was the original inspiration
for this change.
I ran this idea by Jim Grosbach a few weeks ago & he was OK with it.
Since it's a basically mechanical patch that seemed sufficient - usual
post-commit review, revert, etc, as needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210427 91177308-0d34-0410-b5e6-96231b3b80d8
* 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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210367 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210298 91177308-0d34-0410-b5e6-96231b3b80d8
This makes LLVM create N_INDR aliases (to be resolved by the linker) when
appropriate.
rdar://problem/15125513
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209894 91177308-0d34-0410-b5e6-96231b3b80d8
Now that clang can be used as an assembler via the IAS, invalid assembler inputs
would cause the assertions to trigger. Although we cannot recover from the
errors here, nor provide caret diagnostics, attempt to handle them slightly more
gracefully by reporting a fatal error.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209387 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r208930, r208933, and r208975.
It seems not all fission consumers are ready to handle this behavior.
Reverting until tools are brought up to spec.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209338 91177308-0d34-0410-b5e6-96231b3b80d8
Add support to allow a target specific COFF object writer to restrict the
recorded resolutions in the emitted object files. This is motivated by the need
in Windows on ARM, where an intermediate relocation needs to be prevented from
being emitted in the object file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209336 91177308-0d34-0410-b5e6-96231b3b80d8
Since type units in the dwo file are handled by a debug aware tool, they
don't need to leverage the ELF comdat grouping to implement
deduplication. Avoid creating all the .group sections for these as a
space optimization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208930 91177308-0d34-0410-b5e6-96231b3b80d8
The old method used by X86TTI to determine partial-unrolling thresholds was
messy (because it worked by testing target features), and also would not
correctly identify the target CPU if certain target features were disabled.
After some discussions on IRC with Chandler et al., it was decided that the
processor scheduling models were the right containers for this information
(because it is often tied to special uop dispatch-buffer sizes).
This does represent a small functionality change:
- For generic x86-64 (which uses the SB model and, thus, will get some
unrolling).
- For AMD cores (because they still currently use the SB scheduling model)
- For Haswell (based on benchmarking by Louis Gerbarg, it was decided to bump
the default threshold to 50; we're working on a test case for this).
Otherwise, nothing has changed for any other targets. The logic, however, has
been moved into BasicTTI, so other targets may now also opt-in to this
functionality simply by setting LoopMicroOpBufferSize in their processor
model definitions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208289 91177308-0d34-0410-b5e6-96231b3b80d8
This removes arguments passed everywhere and allows the use of
standard iteration over lists.
Should be no functional change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208127 91177308-0d34-0410-b5e6-96231b3b80d8
The fix itself is fairly simple: move getAccessVariant to MCValue so that we
replace the old weak expression evaluation with the far more general
EvaluateAsRelocatable.
This then requires that EvaluateAsRelocatable stop when it finds a non
trivial reference kind. And that in turn requires the ELF writer to look
harder for weak references.
Last but not least, this found a case where we were being bug by bug
compatible with gas and accepting an invalid input. I reported pr19647
to track it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207920 91177308-0d34-0410-b5e6-96231b3b80d8
This simplifies ELFObjectWriter::SymbolValue a bit more. This new version
will also be used in the COFF writer to fix pr19147.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207711 91177308-0d34-0410-b5e6-96231b3b80d8
This patch centralizes the handling of the thumb bit around
MCStreamer::isThumbFunc and makes isThumbFunc handle aliases.
This fixes a corner case, but the main advantage is having just one
way to check if a MCSymbol is thumb or not. This should still be
refactored to be ARM only, but at least now it is just one predicate
that has to be refactored instead of 3 (isThumbFunc,
ELF_Other_ThumbFunc, and SF_ThumbFunc).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207522 91177308-0d34-0410-b5e6-96231b3b80d8
When evaluating an assembly expression for a relocation, we want to
stop at MCSymbols that are in the symbol table, even if they are variables.
This is needed since the semantics may require that the relocation use them.
That is not the case when computing the value of a symbol in the symbol table.
There are no relocations in this case and we have to keep going until we hit
a section or find out that the expression doesn't have an assembly time
value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207445 91177308-0d34-0410-b5e6-96231b3b80d8
This introduces a target specific streamer, X86WinCOFFStreamer, which handles
the target specific behaviour (e.g. WinEH). This is mostly to ensure that
differences between ARM and X86 remain disjoint and do not accidentally cross
boundaries. This is the final staging change for enabling object emission for
Windows on ARM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207344 91177308-0d34-0410-b5e6-96231b3b80d8
This is in preparation for promoting WinCOFFStreamer to a base class which will
be shared by the X86 and ARM specific target COFF streamers. Also add a new
getOrCreateSymbolData interface (like MCELFStreamer) for the ARM COFF Streamer.
This makes the COFFStreamer more similar to the ELFStreamer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207343 91177308-0d34-0410-b5e6-96231b3b80d8
I discovered this const-hole while attempting to coalesnce the Symbol
and SymbolMap data structures. There's some pending issues with that,
but I figured this change was easy to flush early.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207124 91177308-0d34-0410-b5e6-96231b3b80d8
For now it contains a single flag, SanitizeAddress, which enables
AddressSanitizer instrumentation of inline assembly.
Patch by Yuri Gorshenin.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206971 91177308-0d34-0410-b5e6-96231b3b80d8
from places like MCCodeEmitter() in the MC backend when the
MCContext is const.
I was going to use this in my change for r206669 but Jim convinced
me to use an assert there. But this still is a good tweak.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206923 91177308-0d34-0410-b5e6-96231b3b80d8
diagnostic that includes location information.
Currently if one has this assembly:
.quad (0x1234 + (4 * SOME_VALUE))
where SOME_VALUE is undefined ones gets the less than
useful error message with no location information:
% clang -c x.s
clang -cc1as: fatal error: error in backend: expected relocatable expression
With this fix one now gets a more useful error message
with location information:
% clang -c x.s
x.s:5:8: error: expected relocatable expression
.quad (0x1234 + (4 * SOME_VALUE))
^
To do this I plumbed the SMLoc through the MCObjectStreamer
EmitValue() and EmitValueImpl() interfaces so it could be used
when creating the MCFixup.
rdar://12391022
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206906 91177308-0d34-0410-b5e6-96231b3b80d8
MCModule's ctor had to be moved out of line so the definition of
MCFunction was available. (ctor requires the dtor of members (in case
the ctor throws) which required access to the dtor of MCFunction)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206244 91177308-0d34-0410-b5e6-96231b3b80d8
This patch re-introduces the MCContext member that was removed from
MCDisassembler in r206063, and requires that an MCContext be passed in at
MCDisassembler construction time. (Previously the MCContext member had been
initialized in an ad-hoc fashion after construction). The MCCContext member
can be used by MCDisassembler sub-classes to construct constant or
target-specific MCExprs.
This patch updates disassemblers for in-tree targets, and provides the
MCRegisterInfo instance that some disassemblers were using through the
MCContext (previously those backends were constructing their own
MCRegisterInfo instances).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206241 91177308-0d34-0410-b5e6-96231b3b80d8
MCDisassembler has an MCSymbolizer member that is meant to take care of
symbolizing during disassembly, but it also has several methods that enable the
disassembler to do symbolization internally (i.e. without an attached symbolizer
object). There is no need for this duplication, but ARM64 had been making use of
it. This patch moves the ARM64 symbolization logic out of ARM64Disassembler and
into an ARM64ExternalSymbolizer class, and removes the duplicated MCSymbolizer
functionality from the MCDisassembler interface. Symbolization will now be
done exclusively through MCSymbolizers.
There should be no impact on disassembly for any platform, but this allows us to
tidy up the MCDisassembler interface and simplify the process of (and invariants
related to) disassembler setup.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206063 91177308-0d34-0410-b5e6-96231b3b80d8
This seems to have been a cargo-culted habit from the very first such
cache which didn't have any specific justification (but might've been a
layering constraint at the time).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206003 91177308-0d34-0410-b5e6-96231b3b80d8
To support compressing the debug_line section that contains multiple
fragments (due, I believe, to variation in choices of line table
encoding depending on the size of instruction ranges in the actual
program code) we needed to support compressing multiple MCFragments in a
single pass.
This patch implements that behavior by mutating the post-relaxed and
relocated section to be the compressed form of its former self,
including renaming the section.
This is a more flexible (and less invasive, to a degree) implementation
that will allow for other features such as "use compression only if it's
smaller than the uncompressed data".
Compressing debug_frame would be a possible further extension to this
work, but I've left it for now. The hurdle there is alignment sections -
which might require going as far as to refactor
MCAssembler.cpp:writeFragment to handle writing to a byte buffer or an
MCObjectWriter (there's already a virtual call there, so it shouldn't
add substantial compile-time cost) which could in turn involve
refactoring MCAsmBackend::writeNopData to use that same abstraction...
which involves touching all the backends. This would remove the limited
handling of fragment writing seen in
ELFObjectWriter.cpp:getUncompressedData which would be nice - but it's
more invasive.
I did discover that I (perhaps obviously) don't need to handle
relocations when I rewrite the fragments - since the relocations have
already been applied and computed (and stored into
ELFObjectWriter::Relocations) by this stage (necessarily, because we
need to have written any immediate values or assembly-time relocations
into the data already before we compress it, which we have). The test
case doesn't necessarily cover that in detail - I can add more test
coverage if that's preferred.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205990 91177308-0d34-0410-b5e6-96231b3b80d8
To support compression for debug_line and debug_frame a different
approach is required. To simplify review, revert the old implementation
and XFAIL the test case. New implementation to follow shortly.
Reverts r205059 and r204958.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205989 91177308-0d34-0410-b5e6-96231b3b80d8
This moves one case of raw text checking down into the MCStreamer
interfaces in the form of a virtual function, even if we ultimately end
up consolidating on the one-or-many line tables issue one day, this is
nicer in the interim. This just generally streamlines a bunch of use
cases into a common code path.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205287 91177308-0d34-0410-b5e6-96231b3b80d8
I don't think this is reachable by any frontend (why would you transform
asm to asm+debug info?) but it helps tidy up some of this code, avoid
the weird special case of "emit the first CU, store the label, then emit
the rest" in MCDwarfLineTable::Emit by instead having the
DWARF-for-assembly case use the same codepath as DwarfDebug.cpp, by
registering the label of the debug_line section, thus causing it to be
emitted. (with a special case in asm output to just emit the label since
asm output uses the .loc directives, etc, rather than the debug_loc
directly)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205286 91177308-0d34-0410-b5e6-96231b3b80d8
The ARM64 backend uses it only as a container to keep an MCLOHType and
Arguments around so give it its own little copy. The other functionality
isn't used and we had a crazy method specialization hack in place to
keep it working. Unfortunately that was incompatible with MSVC.
Also range-ify a couple of loops while at it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205114 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a second implementation of the AArch64 architecture to LLVM,
accessible in parallel via the "arm64" triple. The plan over the
coming weeks & months is to merge the two into a single backend,
during which time thorough code review should naturally occur.
Everything will be easier with the target in-tree though, hence this
commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205090 91177308-0d34-0410-b5e6-96231b3b80d8
ARM64 has compact-unwind information, but doesn't necessarily want to
emit .eh_frame directives as well. This teaches MC about such a
situation so that it will skip .eh_frame info when compact unwind has
been successfully produced.
For functions incompatible with compact unwind, the normal information
is still written.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205087 91177308-0d34-0410-b5e6-96231b3b80d8
This is principally to allow neater mapping of fixups to relocations
in ARM64 ELF. Without this, there isn't enough information available
to GetRelocType, leading to many more fixup_arm64_... enumerators.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205085 91177308-0d34-0410-b5e6-96231b3b80d8
Another part of the ARM64 backend (so tests will be following soon).
This is currently used by the linker to relax adrp/ldr pairs into nops
where possible, though could well be more broadly applicable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205084 91177308-0d34-0410-b5e6-96231b3b80d8
The upcoming ARM64 backend doesn't have section-relative relocations,
so we give each section its own symbol to provide this functionality.
Of course, it doesn't need to appear in the final executable, so
linker-private is the best kind for this purpose.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205081 91177308-0d34-0410-b5e6-96231b3b80d8
I started trying to fix a small issue, but this code has seen a small fix too
many.
The old code was fairly convoluted. Some of the issues it had:
* It failed to check if a symbol difference was in the some section when
converting a relocation to pcrel.
* It failed to check if the relocation was already pcrel.
* The pcrel value computation was wrong in some cases (relocation-pc.s)
* It was missing quiet a few cases where it should not convert symbol
relocations to section relocations, leaving the backends to patch it up.
* It would not propagate the fact that it had changed a relocation to pcrel,
requiring a quiet nasty work around in ARM.
* It was missing comments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205076 91177308-0d34-0410-b5e6-96231b3b80d8
1) When creating a .debug_* section and instead create a .zdebug_
section.
2) When creating a fragment in a .zdebug_* section, make it a compressed
fragment.
3) When computing the size of a compressed section, compress the data
and use the size of the compressed data.
4) Emit the compressed bytes.
Also, check that only if a section has a compressed fragment, then that
is the only fragment in the section.
Assert-fail if the fragment's data is modified after it is compressed.
Initial review on llvm-commits by Eric Christopher and Rafael Espindola.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204958 91177308-0d34-0410-b5e6-96231b3b80d8
While at it, factor some logic into FragmentWriter. This will allow more code
to be factored out of the fairly large ELFObjectWriter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204765 91177308-0d34-0410-b5e6-96231b3b80d8
Given
bar = foo + 4
.long bar
MC would eat the 4. GNU as includes it in the relocation. The rule seems to be
that a variable that defines a symbol is used in the relocation and one that
does not define a symbol is evaluated and the result included in the relocation.
Fixing this unfortunately required some other changes:
* Since the variable is now evaluated, it would prevent the ELF writer from
noticing the weakref marker the elf streamer uses. This patch then replaces
that with a VariantKind in MCSymbolRefExpr.
* Using VariantKind then requires us to look past other VariantKind to see
.weakref bar,foo
call bar@PLT
doing this also fixes
zed = foo +2
call zed@PLT
so that is a good thing.
* Looking past VariantKind means that the relocation selection has to use
the fixup instead of the target.
This is a reboot of the previous fixes for MC. I will watch the sanitizer
buildbot and wait for a build before adding back the previous fixes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204294 91177308-0d34-0410-b5e6-96231b3b80d8
This isn't a complete fix - it falls back to non-comp_dir when multiple
compile units are in play. Adding a map of comp_dir to table is part of
the more general solution, but I gave up (in the short term) when I
realized I'd also have to calculate the size of each type unit so as to
produce correct DW_AT_stmt_list attributes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204202 91177308-0d34-0410-b5e6-96231b3b80d8
Allow object files to be tagged with a version-min load command for iOS
or MacOSX.
Teach macho-dump to understand the version-min load commands for
testcases.
rdar://11337778
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204190 91177308-0d34-0410-b5e6-96231b3b80d8
The revision I'm reverting breaks handling of transitive aliases. This blocks us
and breaks sanitizer bootstrap:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/2651
(and checked locally by Alexey).
This revision is the result of:
svn merge -r204059:204058 -r204028:204027 -r203962:203961 .
+ the regression test added to test/MC/ELF/alias.s
Another way to reproduce the regression with clang:
$ cat q.c
void a1();
void a2() __attribute__((alias("a1")));
void a3() __attribute__((alias("a2")));
void a1() {}
$ ~/work/llvm-build/bin/clang-3.5-good -c q.c && mv q.o good.o && \
~/work/llvm-build/bin/clang-3.5-bad -c q.c && mv q.o bad.o && \
objdump -t good.o bad.o
good.o: file format elf64-x86-64
SYMBOL TABLE:
0000000000000000 l df *ABS* 0000000000000000 q.c
0000000000000000 l d .text 0000000000000000 .text
0000000000000000 l d .data 0000000000000000 .data
0000000000000000 l d .bss 0000000000000000 .bss
0000000000000000 l d .comment 0000000000000000 .comment
0000000000000000 l d .note.GNU-stack 0000000000000000 .note.GNU-stack
0000000000000000 l d .eh_frame 0000000000000000 .eh_frame
0000000000000000 g F .text 0000000000000006 a1
0000000000000000 g F .text 0000000000000006 a2
0000000000000000 g F .text 0000000000000006 a3
bad.o: file format elf64-x86-64
SYMBOL TABLE:
0000000000000000 l df *ABS* 0000000000000000 q.c
0000000000000000 l d .text 0000000000000000 .text
0000000000000000 l d .data 0000000000000000 .data
0000000000000000 l d .bss 0000000000000000 .bss
0000000000000000 l d .comment 0000000000000000 .comment
0000000000000000 l d .note.GNU-stack 0000000000000000 .note.GNU-stack
0000000000000000 l d .eh_frame 0000000000000000 .eh_frame
0000000000000000 g F .text 0000000000000006 a1
0000000000000000 g F .text 0000000000000006 a2
0000000000000000 g .text 0000000000000000 a3
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204137 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce a slightly tighter wrapper around the header structure that
handles this use case. (MCDwarfDwoLineTable)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204101 91177308-0d34-0410-b5e6-96231b3b80d8
Our handling of compilation directory in DwarfDebug was broken
(incorrectly using the 'last' compilation directory (that of the last
CU in the metadata list) for all function emission in any CU). By moving
this handling down into MCDwarf the issue is fixed as the compilation
dir is tracked correctly per line table.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204089 91177308-0d34-0410-b5e6-96231b3b80d8
See r204027 for the precursor to this that applied to asm debug info.
This required some non-obvious API changes to handle the case of asm
output (we never go asm->asm so this didn't come up in r204027): the
modification of the file/directory name by MCDwarfLineTableHeader needed
to be reflected in the MCAsmStreamer caller so it could print the
appropriate .file directive, so those StringRef parameters are now
non-const ref (in/out) parameters rather than just const.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204069 91177308-0d34-0410-b5e6-96231b3b80d8
The previous deduping strategy was woefully inadequate - it only
considered the most recent file used and avoided emitting a duplicate in
that case - never considering the a/b/a scenario.
It was also lacking when it came to directory paths as the previous
filename would never match the current if the filename had been split
into file and directory components.
This change builds caching functionality into the line table at the
lowest level in an optional form (a file number of 0 indicates that one
should be chosen and returned) and will eventually be reused by the
normal source level debugging DWARF emission.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204027 91177308-0d34-0410-b5e6-96231b3b80d8
This sometimes remains null into MCLineTableHeader::Emit where we
conditionally construct a label if one isn't provided for us. We need it
to remain null (rather than just always constructing the label) so we
can identify unused line tables... which is a bit weird and maybe we can
do away with that logic one day (& on that day we can always construct
the label up-front and just have compilation units query the line table
for its label, etc)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203967 91177308-0d34-0410-b5e6-96231b3b80d8
We were marking the symbol as absolute instead of computing b's offset + the
expression value.
This fixes pr19126.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203962 91177308-0d34-0410-b5e6-96231b3b80d8
This type now represents all the data for the DWARF line table:
directory names, file names, and the line table proper.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203858 91177308-0d34-0410-b5e6-96231b3b80d8
There aren't /that/ many files, and we are already using various maps
and other standard containers that don't use MCContext's allocator to
store these values, so this doesn't seem to be critical and simplifies
the design (I'll be moving construction out of MCContext shortly so it'd
be annoying to have to pass the allocator around to allocate these
things... and we'll have non-MCContext users (debug_line.dwo) shortly)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203831 91177308-0d34-0410-b5e6-96231b3b80d8
This changes the implementation of local directional labels to use a dedicated
map. With that it can then just use CreateTempSymbol, which is what the rest
of MC uses.
CreateTempSymbol doesn't do a great job at making sure the names are unique
(or being efficient when the names are not needed), but that should probably
be fixed in a followup patch.
This fixes pr18928.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203826 91177308-0d34-0410-b5e6-96231b3b80d8
This replaces several "compile unit ID -> thing" mappings in favor of
one mapping from CUID to the whole line table structure (files,
directories, and lines).
This is another step along the way to refactoring out reusable
components of line table handling for use when generating debug_line.dwo
for fission type units.
Also, might be a good basis to fold some of this handling down into
MCStreamers to avoid the special case of "One line table when doing asm
printing, line table per CU otherwise" by building it into the different
MCStreamer implementations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203821 91177308-0d34-0410-b5e6-96231b3b80d8
This is a follow-up to r203635. Saleem pointed out that since symbolic register
names are much easier to read, it would be good if we could turn them off only
when we really need to because we're using an external assembler.
Differential Revision: http://llvm-reviews.chandlerc.com/D3056
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203806 91177308-0d34-0410-b5e6-96231b3b80d8
This makes the mapping consistent with other CU->X mappings in the
MCContext, helping pave the way to refactor all these values into a
single data structure per CU and thus a single map.
I haven't renamed the data structure as that would make the patch churn
even higher (the MCLineSection name no longer makes sense, as this
structure now contains lines for multiple sections covered by a single
CU, rather than lines for a single section in multiple CUs) and further
refactorings will follow that may remove this type entirely.
For convenience, I also gave the MCLineSection value semantics so we
didn't have to do the lazy construction, manual delete, etc.
(& for those playing at home, refactoring the line printing into a
single data structure will eventually alow that data structure to be
reused to own the debug_line.dwo line table used for type unit file name
resolution)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203726 91177308-0d34-0410-b5e6-96231b3b80d8
When printing assembly we don't have a Layout object, but we can still
try to fold some constants.
Testcase by Ulrich Weigand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203677 91177308-0d34-0410-b5e6-96231b3b80d8
The function hasReliableSymbolDifference had exactly one use in the MachO
writer. It is also only true for X86_64. In fact, the comments refers to
"Darwin x86_64" and everything else, so this makes the code match the
comment.
If this is to be abstracted again, it should be a property of
TargetObjectWriter, like useAggressiveSymbolFolding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203605 91177308-0d34-0410-b5e6-96231b3b80d8
This is a straightfoward replacement, it makes debugging a little
easier.
This has no functional impact.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203264 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
llvm/MC/MCSectionMachO.h and llvm/Support/MachO.h both had the same
definitions for the section flags. Instead, grab the definitions out of
support.
No functionality change.
Reviewers: grosbach, Bigcheese, rafael
Reviewed By: rafael
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2998
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203211 91177308-0d34-0410-b5e6-96231b3b80d8
This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203083 91177308-0d34-0410-b5e6-96231b3b80d8
Before llvm-mc would print it, but llc was assuming that it would produce
another section changing directive before one was needed. That assumption is
false with inline asm.
Fixes PR19049.
Another option would be to always create the section, but in the asm printer
avoid printing sections changes during initialization. That would work, but
* We do use the fact that llvm-mc prints it in testing. The tests can be changed
if needed.
* A quick poll on IRC suggest that most developers prefer the implicit .text to
be printed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203001 91177308-0d34-0410-b5e6-96231b3b80d8
This will allow external callers of these functions to switch over time
rather than forcing a breaking change all a once. These particular
functions were determined by building clang/lld/lldb.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202959 91177308-0d34-0410-b5e6-96231b3b80d8
