This makes the coff writer compute the correct symbol value for the test in
pr19147. The section is still incorrect, that will be fixed in a followup patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207728 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
We already do this for shstrtab, so might as well do it for strtab. This
extracts the string table building code into a separate class. The idea
is to use it for other object formats too.
I mostly wanted to do this for the general principle, but it does save a
little bit on object file size. I tried this on a clang bootstrap and
saved 0.54% on the sum of object file sizes (1.14 MB out of 212 MB for
a release build).
Differential Revision: http://reviews.llvm.org/D3533
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207670 91177308-0d34-0410-b5e6-96231b3b80d8
This is a partial port of r204816 (cpirker "Elf support for MC-JIT
runtime dynamic linker") from AArch64 to ARM64.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207625 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
The symbol table itself has no relocations, so it is not possible to represent
things like
a = undefined + 1
With the patch we just omit these variables. That matches the behaviour of the
gnu assembler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207419 91177308-0d34-0410-b5e6-96231b3b80d8
Only the object streamers need to track if a symbol should be marked thumb or
not. This ports the ELF case. The COFF case is not ported since it is currently
not working for some other reason (I will report a bug).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207366 91177308-0d34-0410-b5e6-96231b3b80d8
This restores the previous behaviour of just assuming that if you dont specify a
valid triple that you really meant the default triple with an ELF object file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207349 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce support for WoA PE/COFF object file emission from LLVM. Add the new
target specific PE/COFF Streamer (ARMWinCOFFStreamer) that handles the ARM
specific behaviour of PE/COFF object emission. ARM exception information is not
yet emitted and is a TODO item.
The ARM specific object writer (ARMWinCOFFObjectWriter) handles the ARM specific
relocation handling in conjunction with the WinCOFFObjectWriter in the MC layer.
The MC layer needs to be updated to deal with the relocation adjustments.
Branch relocations are adjusted by 4 bytes (unlikely their ELF counterparts).
Minor tweaks to switch multiple conditional checks into equivalent switch
statements. The ObjectFileInfo is updated to relax the object file setup for
Windows COFF. Move the architecture checks into an assertion. Windows COFF is
currently only supported on x86, x86_64, and ARM (thumb). Rather than
defaulting to ELF, we will refuse to generate an object file. This is better
though as you do not get an (arbitrary) object file which is different from the
request.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207345 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
Stylistic changes to prepare for splitting up the COFFStreamer into target
specific streamers. Tweak some assertion messages. No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207342 91177308-0d34-0410-b5e6-96231b3b80d8
When fixing the symbols in each compressed section we were iterating
over all symbols for each compressed section. In extreme cases this
could snowball severely (5min uncompressed -> 35min compressed) due to
iterating over all symbols for each compressed section (large numbers of
compressed sections can be generated by DWARF type units).
To address this, build a map of the symbols in each section ahead of
time, and access that map if a section is being compressed. This brings
compile time for the aforementioned example down to ~6 minutes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207167 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
Leak identified by LSan and reported by Kostya Serebryany.
Let's get a bit experimental here... in theory our minimum compiler
versions support unordered_map.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207118 91177308-0d34-0410-b5e6-96231b3b80d8
Emit the flag to indicate to the assembler that a section contains data if there
is pre-populated data present.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207028 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
definition below all the header #include lines. This updates most of the
miscellaneous other lib/... directories. A few left though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206845 91177308-0d34-0410-b5e6-96231b3b80d8
behavior based on other files defining DEBUG_TYPE, which means it cannot
define DEBUG_TYPE at all. This is actually better IMO as it forces folks
to define relevant DEBUG_TYPEs for their files. However, it requires all
files that currently use DEBUG(...) to define a DEBUG_TYPE if they don't
already. I've updated all such files in LLVM and will do the same for
other upstream projects.
This still leaves one important change in how LLVM uses the DEBUG_TYPE
macro going forward: we need to only define the macro *after* header
files have been #include-ed. Previously, this wasn't possible because
Debug.h required the macro to be pre-defined. This commit removes that.
By defining DEBUG_TYPE after the includes two things are fixed:
- Header files that need to provide a DEBUG_TYPE for some inline code
can do so by defining the macro before their inline code and undef-ing
it afterward so the macro does not escape.
- We no longer have rampant ODR violations due to including headers with
different DEBUG_TYPE definitions. This may be mostly an academic
violation today, but with modules these types of violations are easy
to check for and potentially very relevant.
Where necessary to suppor headers with DEBUG_TYPE, I have moved the
definitions below the includes in this commit. I plan to move the rest
of the DEBUG_TYPE macros in LLVM in subsequent commits; this one is big
enough.
The comments in Debug.h, which were hilariously out of date already,
have been updated to reflect the recommended practice going forward.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206822 91177308-0d34-0410-b5e6-96231b3b80d8
Both ZLIB and the debug info compressed section header ("ZLIB" + the
size of the uncompressed data) take some constant overhead so in some
cases the compressed data is actually larger than the uncompressed data.
In these cases, just don't compress or rename the section at all.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206659 91177308-0d34-0410-b5e6-96231b3b80d8
While unnamed relocations are already cached in side tables in
ELFObjectWriter::RecordRelocation, symbols still need their fragments
updated to refer to the newly compressed fragment (even if that fragment
isn't big enough to fit the offset). Even though we only create
temporary symbols in debug info sections this comes up in 32 bit builds
where even temporary symbols in mergeable sections (such as debug_str)
have to be emitted as named symbols.
I tried a few other ways to do this but they all didn't work for various
reasons:
1) Canonicalize the MCSymbolData in RecordRelocation, nulling out the
Fragment (so it didn't have to be updated by CompressDebugSection). This
doesn't work because some code relies on symbols having fragments to
indicate that they're defined, I think.
2) Canonicalize the MCSymbolData in RecordRelocation to be "first
fragment + absolute offset" so it would be cheaper to just test and
update the fragment in CompressDebugSections. This doesn't work because
the offset computed in RecordRelocation isn't that of the symbol's
fragment, it's the passed in fragment (I haven't figured out what that
fragment is - perhaps it's the location where the relocation is to be
written). And if the fragment offset has to be computed only for this
use we might as well just do it when we need to, in
CompressDebugSection.
I also added an assert to help catch this a bit more clearly, even
though it is UB. The test case improvements would either assert fail
and/or valgrind vail without the fix, even if they wouldn't necessarily
fail the FileCheck output.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206653 91177308-0d34-0410-b5e6-96231b3b80d8
This commit was attributed to a different person from the person who
posted the patch to the list, and the person who posted it the list
claimed when they did that they were not the author, but that the author
was yet a third person. I don't know what is going on here, but
reverting until the attribution is clear and the author has explicitly
contributed the patch.
Also, the review hasn't really involved any of the MC maintainers and
that seems questionable too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206576 91177308-0d34-0410-b5e6-96231b3b80d8
Visual Studio does not permit referencing a structure member as a static field
for sizeof calculations. Resort to a pointer cast which is compatible across
Visual Studio and other compilers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206445 91177308-0d34-0410-b5e6-96231b3b80d8
The most important part here is that we should actuall emit the stubs we refer
to in the exception table, but as a side issue this uses more sensible & GCC
compatible representations for some of the bits of information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206380 91177308-0d34-0410-b5e6-96231b3b80d8
Adjust the tests to validate the number of auxiliary entries used to store the
filename.
Thanks to majnemer's sharp eye for catching the missing - 1 in the round up
calculation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206359 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for emitting .file records. This is mostly a quality of
implementation change (more complete support for COFF file emission) that was
noticed while working on COFF file emission for Windows on ARM.
A .file record is emitted as a symbol with storage class FILE (103) and the name
".file". A series of auxiliary format 4 records follow which contain the file
name. The filename is stored as an ANSI string and is padded with NULL if the
length is not a multiple of COFF::SymbolSize (18).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206355 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
Currently, we bind those directives with the last symbol, so if none
has been defined, this would lead to a crash of the compiler.
<rdar://problem/15939159>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206236 91177308-0d34-0410-b5e6-96231b3b80d8
This allows correct relocations to be generated for a symbolic
address that is being adjusted by a negative constant. Since r204294,
such expressions have triggered undefined behavior when LLVM was built
without assertions.
Credit goes to Rafael for this patch; I'm submitting it on his behalf
as he is on vacation this week.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206192 91177308-0d34-0410-b5e6-96231b3b80d8
The values for the relocation type can (and do) overlap across various
architectures. When performing an adjustment of the emitted relocation in the
final object file, check that the file magic matches the target for which the
relocation type is valid (e.g. a I386 relocation is only applied to an X86
object file, and an AMD64 relocation is only applied to an X86_64 object file).
This was noticed while adding support for ARM WinCOFF object file emission.
A test case for this is not really possible as the values for REL32 do not
overlap on I386 and AMD64, which is why this was never noticed in practice. The
ARM WinCOFF emission is not yet ready to merge into the tree.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206138 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
Introduce ScalarTraits::mustQuote which determines whether or not a
StringRef needs quoting before it is acceptable to output.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205955 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Local common symbols were properly inserted into the .bss section.
However, putting external common symbols in the .bss section would give
them a strong definition.
Instead, encode them as undefined, external symbols who's symbol value
is equivalent to their size.
Reviewers: Bigcheese, rafael, rnk
CC: llvm-commits
Differential Revision: http://reviews.llvm.org/D3324
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205811 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
Turns out debug_frame does use multiple fragments, so it doesn't
compress correctly with the current approach. Disable compressing it for
now while I figure out what's the best solution for it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205059 91177308-0d34-0410-b5e6-96231b3b80d8
Construct a uniform Windows target triple nomenclature which is congruent to the
Linux counterpart. The old triples are normalised to the new canonical form.
This cleans up the long-standing issue of odd naming for various Windows
environments.
There are four different environments on Windows:
MSVC: The MS ABI, MSVCRT environment as defined by Microsoft
GNU: The MinGW32/MinGW32-W64 environment which uses MSVCRT and auxiliary libraries
Itanium: The MSVCRT environment + libc++ built with Itanium ABI
Cygnus: The Cygwin environment which uses custom libraries for everything
The following spellings are now written as:
i686-pc-win32 => i686-pc-windows-msvc
i686-pc-mingw32 => i686-pc-windows-gnu
i686-pc-cygwin => i686-pc-windows-cygnus
This should be sufficiently flexible to allow us to target other windows
environments in the future as necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204977 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
Allows this test to pass on COFF platforms so we don't need to restrict
this test to a single target anymore.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204780 91177308-0d34-0410-b5e6-96231b3b80d8
The logic was incorrect for variables, causing them to end up in the wrong
section if the section had an index >= 0xff00.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204771 91177308-0d34-0410-b5e6-96231b3b80d8
We need .symtab_shndxr if and only if a symbol references a section with an
index >= 0xff00.
The old code was trying to figure out if the section was needed ahead of time,
making it a fairly dependent on the code actually writing the table. It was
also somewhat conservative and would create the section in cases where it was
not needed.
If I remember correctly, the old structure was there so that the sections were
created in the same order gas creates them. That was valuable when MC's support
for ELF was new and we tested with elf-dump.py.
This patch refactors the symbol table creation to another class and makes it
obvious that .symtab_shndxr is really only created when we are about to output
a reference to a section index >= 0xff00.
While here, also improve the tests to use macros. One file is one section
short of needing .symtab_shndxr, the second one has just the right number.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204769 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
This is similar, but not identical to what gas does. The logic in MC is to just
compute the symbol table after parsing the entire file. GAS is mixed, given
.type b, @object
a = b
b:
.type b, @function
It will propagate the change and make 'a' a function. Given
.type b, @object
b:
a = b
.type b, @function
the type of 'a' is still object.
Since we do the computation in the end, we produce a function in both cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204555 91177308-0d34-0410-b5e6-96231b3b80d8
When a label is parsed, check if there is type information available for the
label. If so, check if the symbol is a function. If the symbol is a function
and we are in thumb mode and no explicit thumb_func has been emitted, adjust the
symbol data to indicate that the function definition is a thumb function.
The application of this inferencing is improved value handling in the object
file (the required thumb bit is set on symbols which are thumb functions). It
also helps improve compatibility with binutils.
The one complication that arises from this handling is the MCAsmStreamer. The
default implementation of getOrCreateSymbolData in MCStreamer does not support
tracking the symbol data. In order to support the semantics of thumb functions,
track symbol data in assembly streamer. Although O(n) in number of labels in
the TU, this is already done in various other streamers and as such the memory
overhead is not a practical concern in this scenario.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204544 91177308-0d34-0410-b5e6-96231b3b80d8
sym_a:
sym_d = sym_a + 1
This is the smallest fix I was able to extract from what got reverted in
r204203.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204527 91177308-0d34-0410-b5e6-96231b3b80d8
Add an assertion that the section is not NULL. Potential NULL pointer
dereference identified by clang static analyzer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204429 91177308-0d34-0410-b5e6-96231b3b80d8
The function exists to force an expression to be absolute, but there it is not
possible to force a symbol reference since
a = b
.long a
means something else.
This is an alternative fix for pr9951 that uses an assert. It then deletes
the old pr9951 test that was testing nothing already.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204399 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
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
It is unclear how it would be possible to get M to be NULL in normal scenarios.
Change this to an assert rather than a runtime check as per dblakie's
suggestion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204060 91177308-0d34-0410-b5e6-96231b3b80d8
This performs the equivalent of a .set directive in that it creates a symbol
which is an alias for another symbol or value which may possibly be yet
undefined. This directive also has the added property in that it marks the
aliased symbol as being a thumb function entry point, in the same way that the
.thumb_func directive does.
The current implementation fails one test due to an unrelated issue. Functions
within .thumb sections are not marked as thumb_func. The result is that
the aliasee function is not valued correctly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204059 91177308-0d34-0410-b5e6-96231b3b80d8
This is really a consistency fix. Since given
a = b
we propagate the information, we should propagate it too given
a = b + (1 - 1)
Fixes pr19145.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204028 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
For better or worse, this is currently the normal error reporting path
when dealing with backend errors from inline assembly. It's not just
internal compiler issues that come through here, so we shouldn't be
creating a backtrace on this path.
rdar://16329947
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203979 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
Summary:
This adds ObjectFile::section_iterator_range, that allows to write
range-based for-loops running over all sections of a given file.
Several files from lib/ are converted to the new interface. Similar fixes
should be applied to a variety of llvm-* tools.
Reviewers: rafael
Reviewed By: rafael
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3069
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203799 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
Split by comma once instead of multiple times. Moving this upfront
makes the rest of the code considerably simpler.
No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203429 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
That was overly aggressive in assuming that we could always assume COFF. Some
of the tests assume that they will get ELF rather than COFF even on Windows
where the default is COFF.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203176 91177308-0d34-0410-b5e6-96231b3b80d8
This is a preliminary setup change to support a renaming of Windows target
triples. Split the object file format information out of the environment into a
separate entity. Unfortunately, file format was previously treated as an
environment with an unknown OS. This is most obvious in the ARM subtarget where
the handling for macho on an arbitrary platform switches to AAPCS rather than
APCS (as per Apple's needs).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203160 91177308-0d34-0410-b5e6-96231b3b80d8
Windows always uses COFF unless Windows ELF is in use. Rather than checking if
Windows, MinGW, or Cygwin is being targeted, just check if the target OS is
windows and that it is not an ELF environment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203159 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
After this I will set the default back to F_None. The advantage is that
before this patch forgetting to set F_Binary would corrupt a file on windows.
Forgetting to set F_Text produces one that cannot be read in notepad, which
is a better failure mode :-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202052 91177308-0d34-0410-b5e6-96231b3b80d8
The .error directive is similar to .err in that it will halt assembly if it is
evaluated for assembly. However, it permits a user supplied message to be
rendered.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201999 91177308-0d34-0410-b5e6-96231b3b80d8
The .ifeqs directive assembles the following code if the quoted string
parameters are equal. The strings must be quoted using double quotes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201998 91177308-0d34-0410-b5e6-96231b3b80d8
The .ifne directive assembles the following section of code if the argument
expression is non-zero. Effectively, it is equivalent to if.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201986 91177308-0d34-0410-b5e6-96231b3b80d8
If the strings are not quoted, the first string stops at the first comma, and
the second string stops at the end of the line. Strings which contain
whitespace should be quoted. Unquoted space is to be discarded.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201985 91177308-0d34-0410-b5e6-96231b3b80d8
The .err directive produces an error whenever it is assembled. This can be
useful for preventing assembly when an unexpected condition occurs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201984 91177308-0d34-0410-b5e6-96231b3b80d8
Offsets past the range of single-slash encoding are encoded as base64,
padded to 6 characters, and prefixed with two slashes. This encoding is
undocumented but used by MSVC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201940 91177308-0d34-0410-b5e6-96231b3b80d8
This commit moves getSLEB128Size() and getULEB128Size() from
MCAsmInfo to LEB128.h and removes some copy-and-paste code.
Besides, this commit also adds some unit tests for the LEB128
functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201937 91177308-0d34-0410-b5e6-96231b3b80d8
This enhances the macro parser to parse and handle parameter qualifications,
which is needed to support required formal parameters in macro definitions. A
required parameter may not be defaulted (though providing a default value is
accepted with a warning). This improves GAS compatibility.
Partially addresses PR9248.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201630 91177308-0d34-0410-b5e6-96231b3b80d8
Rather than using std::pair, create a structure to represent the type. This is
a preliminary refactoring to enable required parameter handling. Additional
state is needed to indicate required parameters. This has a minor side effect
of improving readability by providing more accurate names compared to first and
second.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201629 91177308-0d34-0410-b5e6-96231b3b80d8
Until this point only macro definition with named parameters were parsed but the
names were ignored. This adds support for using that information for named
parameter instantiation.
In order to support the full semantics of the keyword arguments, the arguments
are no longer lazily initialised since the keyword arguments can be specified
out of order and partially if they are defaulted. Prepopulate the arguments
with the default value for any defaulted parameters, and then parse the
specified arguments.
This simplies some of the handling of the arguments in the inner loop since
empty arguments simply increment the parameter index and move on.
Note that keyword and positional arguments cannot be mixed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201499 91177308-0d34-0410-b5e6-96231b3b80d8
The Linux kernel defines empty macros for compatibility with ARM UAL syntax.
The comma after the name is optional, and if present can be safely lexed. This
improves compatibility with the GNU assembler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201474 91177308-0d34-0410-b5e6-96231b3b80d8
Recommitting r201380 (reverted in r201389)
Recommitting r201351 and r201355 (reverted in r201351 and r201355)
We weren't emitting the an empty (header only) line table when the line
table was empty - this made the DWARF invalid (the compile unit would
point to the zero-size debug_lines section where there should've been an
empty line table but there was nothing at all). Fix that, and as a
consequence this works around/addresses PR18809.
Also, we emit a non-empty line table to workaround a darwin linker bug,
so XFAILing on darwin too.
Also, mark the test as 'REQUIRES: object-emission' because it does.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201429 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This adds support for emitting DWARF path discriminator values in
the object streamer. It also changes the DWARF dumper to show
discriminator values in the line table output.
Reviewers: echristo
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2794
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201427 91177308-0d34-0410-b5e6-96231b3b80d8
Recommitting r201351 and r201355 (reverted in r201351 and r201355)
We weren't emitting the an empty (header only) line table when the line
table was empty - this made the DWARF invalid (the compile unit would
point to the zero-size debug_lines section where there should've been an
empty line table but there was nothing at all). Fix that, and as a
consequence this works around/addresses PR18809.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201380 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
There should be a space before each of these two keywords to avoid
generating invalid assembly files.
NOTE: I could not find an obvious maintainers in CODE_OWNERS.TXT, but
this seems related to debug info.
Reviewers: echristo
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2791
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201359 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
AsmPrinter::EmitInlineAsm() will no longer use the EmitRawText() call for
targets with mature MC support. Such targets will always parse the inline
assembly (even when emitting assembly). Targets without mature MC support
continue to use EmitRawText() for assembly output.
The hasRawTextSupport() check in AsmPrinter::EmitInlineAsm() has been replaced
with MCAsmInfo::UseIntegratedAs which when true, causes the integrated assembler
to parse inline assembly (even when emitting assembly output). UseIntegratedAs
is set to true for targets that consider any failure to parse valid assembly
to be a bug. Target specific subclasses generally enable the integrated
assembler in their constructor. The default value can be overridden with
-no-integrated-as.
All tests that rely on inline assembly supporting invalid assembly (for example,
those that use mnemonics such as 'foo' or 'hello world') have been updated to
disable the integrated assembler.
Changes since review (and last commit attempt):
- Fixed test failures that were missed due to configuration of local build.
(fixes crash.ll and a couple others).
- Fixed tests that happened to pass because the local build was on X86
(should fix 2007-12-17-InvokeAsm.ll)
- mature-mc-support.ll's should no longer require all targets to be compiled.
(should fix ARM and PPC buildbots)
- Object output (-filetype=obj and similar) now forces the integrated assembler
to be enabled regardless of default setting or -no-integrated-as.
(should fix SystemZ buildbots)
Reviewers: rafael
Reviewed By: rafael
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2686
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201333 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
AsmPrinter::EmitInlineAsm() will no longer use the EmitRawText() call for targets with mature MC support. Such targets will always parse the inline assembly (even when emitting assembly). Targets without mature MC support continue to use EmitRawText() for assembly output.
The hasRawTextSupport() check in AsmPrinter::EmitInlineAsm() has been replaced with MCAsmInfo::UseIntegratedAs which when true, causes the integrated assembler to parse inline assembly (even when emitting assembly output). UseIntegratedAs is set to true for targets that consider any failure to parse valid assembly to be a bug. Target specific subclasses generally enable the integrated assembler in their constructor. The default value can be overridden with -no-integrated-as.
All tests that rely on inline assembly supporting invalid assembly (for example, those that use mnemonics such as 'foo' or 'hello world') have been updated to disable the integrated assembler.
Reviewers: rafael
Reviewed By: rafael
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2686
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201237 91177308-0d34-0410-b5e6-96231b3b80d8
Some of the more complex directive and macro handling for GAS compatibility
requires lookahead. Add a single token lookahead in the MCAsmLexer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201058 91177308-0d34-0410-b5e6-96231b3b80d8
This enables a slightly odd feature of gas. The macro is defined when
the outermost macro is instantiated.
PR18599
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201045 91177308-0d34-0410-b5e6-96231b3b80d8
This is a small simplification and a small step in fixing pr18743 since
private functions on MachO should be using a 'l' prefix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200994 91177308-0d34-0410-b5e6-96231b3b80d8
This is a nop. doesSectionRequireSymbols is only used from
isSymbolLinkerVisible. isSymbolLinkerVisible only use from ELF was in
if (!Asm.isSymbolLinkerVisible(Symbol) && !Symbol.isUndefined())
return false;
if (Symbol.isTemporary())
return false;
If the symbol is a temporary this code returns false and it is irrelevant if
we take the first if or not. If the symbol is not a temporary,
Asm.isSymbolLinkerVisible returns true without ever calling
doesSectionRequireSymbols.
This was an horrible leftover from when support for ELF was first added.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200894 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes the ldr-pseudo implementation to work when used in
inline assembly. The fix is to move arm assembler constant pools
from the ARMAsmParser class to the ARMTargetStreamer class.
Previously we kept the assembler generated constant pools in the
ARMAsmParser object. This does not work for inline assembly because
a new parser object is created for each blob of inline assembly.
This patch moves the constant pools to the ARMTargetStreamer class
so that the constant pool will remain alive for the entire code
generation process.
An ARMTargetStreamer class is now required for the arm backend.
There was no existing implementation for MachO, only Asm and ELF.
Instead of creating an empty MachO subclass, we decided to make the
ARMTargetStreamer a non-abstract class and provide default
(llvm_unreachable) implementations for the non constant-pool related
methods.
Differential Revision: http://llvm-reviews.chandlerc.com/D2638
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200777 91177308-0d34-0410-b5e6-96231b3b80d8
This is a minimal implementation which accepts only constants rather than
full expressions, but that should be perfectly sufficient for all known
users for now.
Patch from PaX Team <pageexec@freemail.hu>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200614 91177308-0d34-0410-b5e6-96231b3b80d8
This will be needed for .octa support, but we don't want to just use the
existing AsmLexer::Integer for it and then have to litter all its users
with explicit checks for the size, and make them use the new get APIntVal()
method.
So let the lexer produce an AsmLexer::Integer as before for numbers which
are small enough — which appears to cover what was previously a nasty
special case handling of numbers which don't fit in int64_t but *do* fit
in uint64_t.
Where the number is too large even for that, produce an AsmLexer::BigNum
instead. We do nothing with these except complain about them for now,
but that will be changed shortly...
Based on a patch from PaX Team <pageexec@freemail.hu>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200613 91177308-0d34-0410-b5e6-96231b3b80d8
Per the GAS documentation, .fill should permit pattern widths that
aren't a power of two. While I was in the neighborhood, I added some
sanity checking. This change was motivated by a use of this construct
in the Linux Kernel.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200606 91177308-0d34-0410-b5e6-96231b3b80d8
To remove this one simply move the end of file logic from the asm printer to
the target mc streamer.
This removes the last call to hasRawTextSupport from lib/Target.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200590 91177308-0d34-0410-b5e6-96231b3b80d8
This enhances the ARMAsmParser to handle .tlsdescseq directives. This is a
slightly special relocation. We must be able to generate them, but not consume
them in assembly. The relocation is meant to assist the linker in generating a
TLS descriptor sequence. The ELF target streamer is enhanced to append
additional fixups into the current segment and that is used to emit the new
R_ARM_TLS_DESCSEQ relocations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200448 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for tlsdesc relocations which are part of the ABI, marked as
experimental. These relocations permit the linker to perform TLS reference
optimizations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200447 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for TLS CALL relocations. TLS CALL relocations are used to
indicate to the linker to generate appropriate entries to resolve TLS references
via an appropriate function invocation (e.g. __tls_get_addr(PLT)).
In order to accomodate the linker relaxation of the TLS access model for the
references (GD/LD -> IE, IE -> LE), the relocation addend must be incomplete.
This requires that the partial inplace value is also incomplete (i.e. 0). We
simply avoid the offset value calculation at the time of the fixup adjustment in
the ARM assembler backend.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200446 91177308-0d34-0410-b5e6-96231b3b80d8
None of the object file formats reported error on iterator increment. In
retrospect, that is not too surprising: no object format stores symbols or
sections in a linked list or other structure that requires chasing pointers.
As a consequence, all error checking can be done on begin() and end().
This reduces the text segment of bin/llvm-readobj in my machine from 521233 to
518526 bytes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200442 91177308-0d34-0410-b5e6-96231b3b80d8
The linux kernel makes uses of a GAS `feature' which substitutes nothing
for macro arguments which aren't specified.
Proper support for these kind of macro arguments necessitated a cleanup of
differences between `GAS' and `Darwin' dialect macro processing.
Differential Revision: http://llvm-reviews.chandlerc.com/D2634
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200409 91177308-0d34-0410-b5e6-96231b3b80d8
Use an RAII object Instead of inserting a call to
AsmLexer::setSkipSpace(true) in all error paths.
No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200358 91177308-0d34-0410-b5e6-96231b3b80d8
Needed to fix PR18303 to correctly re-encode the instruction if it
is relaxed.
We keep a copy of the MCSubtargetInfo to make sure that we are not
effected by future changes to the subtarget info coming from the
assembler (e.g. when parsing .code 16 directived).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200347 91177308-0d34-0410-b5e6-96231b3b80d8
This commit allows LLVM MC to process .cfi_startproc directives when
they are followed by an additional `simple' identifier. This signals to
elide the emission of target specific CFI instructions that would
normally occur initially.
This fixes PR16587.
Differential Revision: http://llvm-reviews.chandlerc.com/D2624
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200227 91177308-0d34-0410-b5e6-96231b3b80d8
An emitted diagnostic for an invalid relocation variant would place the caret on
the token following the relocation variant indicator or at the end of the line
if there was no following token. This change corrects the placement of the
caret to point to the token.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200159 91177308-0d34-0410-b5e6-96231b3b80d8
This has a few advantages:
* Only targets that use a MCTargetStreamer have to worry about it.
* There is never a MCTargetStreamer without a MCStreamer, so we can use a
reference.
* A MCTargetStreamer can talk to the MCStreamer in its constructor.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200129 91177308-0d34-0410-b5e6-96231b3b80d8
Sweep the codebase for common typos. Includes some changes to visible function
names that were misspelt.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200018 91177308-0d34-0410-b5e6-96231b3b80d8
This patch restores the ARM mode if the user's inline assembly
does not. In the object streamer, it ensures that instructions
following the inline assembly are encoded correctly and that
correct mapping symbols are emitted. For the asm streamer, it
emits a .arm or .thumb directive.
This patch does not ensure that the inline assembly contains
the ADR instruction to switch modes at runtime.
The problem we need to solve is code like this:
int foo(int a, int b) {
int r = a + b;
asm volatile(
".align 2 \n"
".arm \n"
"add r0,r0,r0 \n"
: : "r"(r));
return r+1;
}
If we compile this function in thumb mode then the inline assembly
will switch to arm mode. We need to make sure that we switch back to
thumb mode after emitting the inline assembly or we will incorrectly
encode the instructions that follow (i.e. the assembly instructions
for return r+1).
Based on patch by David Peixotto
Change-Id: Ib57f6d2d78a22afad5de8693fba6230ff56ba48b
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199818 91177308-0d34-0410-b5e6-96231b3b80d8
to not guess at a symbol name in some cases.
The problem is that in object files assembled starting at address 0, when
trying to symbolicate something that starts like this:
% cat x.s
_t1:
vpshufd $0x0, %xmm1, %xmm0
the symbolic disassembly can end up like this:
% otool -tV x.o
x.o:
(__TEXT,__text) section
_t1:
0000000000000000 vpshufd $_t1, %xmm1, %xmm0
Which is in this case produced incorrect symbolication.
But it is useful in some cases to use the SymbolLookUp() call back
to guess at some immediate values. For example one like this
that does not have an external relocation entry:
% cat y.s
_t1:
movl $_d1, %eax
.data
_d1: .long 0
% clang -c -arch i386 y.s
% otool -tV y.o
y.o:
(__TEXT,__text) section
_t1:
0000000000000000 movl $_d1, %eax
% otool -rv y.o
y.o:
Relocation information (__TEXT,__text) 1 entries
address pcrel length extern type scattered symbolnum/value
00000001 False long False VANILLA False 2 (__DATA,__data)
So the change is based on it is not likely that an immediate Value
coming from an instruction field of a width of 1 byte, other than branches
and items with relocation, are not likely symbol addresses.
With the change the first case above simply becomes:
% otool -tV x.o
x.o:
(__TEXT,__text) section
_t1:
0000000000000000 vpshufd $0x0, %xmm1, %xmm0
and the second case continues to work as expected.
rdar://14863405
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199698 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for the symbol(tlsldo) relocation. This is required in order to
solve PR18554.
Reviewed by R. Golin, A. Korobeynikov.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199644 91177308-0d34-0410-b5e6-96231b3b80d8
with raw_ostream's write_escaped() method.
For example darwin's otool(1) program that uses the llvm
disassembler now produces disassembly like this:
leaq 0x7b(%rip), %rdi ## literal pool for: "%f\ntoto\n"
and not print the new lines which messes up the output.
rdar://15145300
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199407 91177308-0d34-0410-b5e6-96231b3b80d8
ARM assembly syntax uses @ for a comment, execpt for the second
parameter of the .symver directive which requires @ as part of the
symbol name. This commit fixes the parsing of this directive by
adding a special case for ARM for this one argumnet.
To make the change we had to move the AllowAtInIdentifier variable
to the MCAsmLexer interface (from AsmLexer) and expose a setter for
the value. The ELFAsmParser then toggles this value when parsing
the second argument to the .symver directive for a target that
uses @ as a comment symbol
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199339 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r198865 which reverts r198851.
ASan identified a use-of-uninitialized of the DwarfTypeUnit::Ty variable
in skeleton type units.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198908 91177308-0d34-0410-b5e6-96231b3b80d8
Modern versions of OSX/Darwin's ld (ld64 > 97.17) have an optimisation present that allows the back end to omit relocations (and replace them with an absolute difference) for FDE some text section refs.
This patch allows a backend to opt-in to this behaviour by setting "DwarfFDESymbolsUseAbsDiff". At present, this is only enabled for modern x86 OSX ports.
test changes by David Fang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198744 91177308-0d34-0410-b5e6-96231b3b80d8
take type from the new symbol but merge them so that the type
is never "downgraded".
This is probably quite rare, except for IFUNC symbols which
we used to misassemble, losing the IFUNC type.
Fixes#18372.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198706 91177308-0d34-0410-b5e6-96231b3b80d8
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.
Also comment and sink the include of "Windows.h" in three .inc files to
match the usage in Memory.inc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198685 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce a new virtual method Note into the AsmParser. This completements the
existing Warning and Error methods. Use the new method to clean up the output
of the unwind routines in the ARM AsmParser.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198661 91177308-0d34-0410-b5e6-96231b3b80d8
SymbolLookUp() call back to return a demangled C++ name to
be used as a comment.
For example darwin's otool(1) program the uses the llvm
disassembler now can produce disassembly like:
callq __ZNK4llvm6Target20createMCDisassemblerERKNS_15MCSubtargetInfoE ## llvm::Target::createMCDisassembler(llvm::MCSubtargetInfo const&) const
Also fix a bug in LLVMDisasmInstruction() that was not flushing
the raw_svector_ostream for the disassembled instruction string
before copying it to the output buffer that was causing truncation
of the output.
rdar://10173828
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198637 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of crashing, raise an error when a subtraction expression
involves an undefined symbol.
This fixes PR18375.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198590 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r198441.
This change doesn't build on Windows, and doesn't do the right thing on
Linux and other platforms that don't use a _Z prefix instead of __Z for
C++ names.
It also had no tests, so it wasn't clear how to fix it forward.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198445 91177308-0d34-0410-b5e6-96231b3b80d8
symbol name, also put the human readable name in a comment.
Also fix a bug in LLVMDisasmInstruction() that was not flushing
the raw_svector_ostream for the disassembled instruction string
before copying it to the output buffer that was causing truncation
of the output.
rdar://10173828
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198441 91177308-0d34-0410-b5e6-96231b3b80d8
Before this patch any program that wanted to know the final symbol name of a
GlobalValue had to link with Target.
This patch implements a compromise solution where the mangler uses DataLayout.
This way, any tool that already links with Target (llc, clang) gets the exact
behavior as before and new IR files can be mangled without linking with Target.
With this patch the mangler is constructed with just a DataLayout and DataLayout
is extended to include the information the Mangler needs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198438 91177308-0d34-0410-b5e6-96231b3b80d8
The GNU assembler supports .rep as an alias for .rept. This simply creates the
alias for it and introduces a test for both .rept and .rep.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198097 91177308-0d34-0410-b5e6-96231b3b80d8
This callback is invoked when the parse has finished successfuly. It
will be used to write out ARM constant pools to implement the ldr
pseudo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197706 91177308-0d34-0410-b5e6-96231b3b80d8
The .end directive indicates the end of the file. No further instructions are
processed after a .end directive is encountered.
One potential (glaringly obvious) optimisation that could be pursued here is to
extend MCAsmParser with a DiscardRemainder method to avoid processing lexemes to
the end of the file. It was unclear at this point if that would be worth
adding, and could easily be added in a follow on change.
Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197547 91177308-0d34-0410-b5e6-96231b3b80d8
Without this, assembling clang's disassembly would produce an object
file with the IMAGE_SCN_CNT_INITIALIZED_DATA section characteristic
rather than the uninitialized one. link.exe would warn when merging
comdats with different flags.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197529 91177308-0d34-0410-b5e6-96231b3b80d8
This commit does not complete the type units feature - there are issues
around fission support (skeletal type units, pubtypes/pubnames) and
hashing of some types including those containing references to types in
other type units.
Originally committed as r197073 and reverted in r197079.
Recommitted as r197197 to reproduce the failure and reverted as r197199
Turns out there was unstable ordering in the type unit dumping code.
Fixed by using MapVector in DWARFContext to store the debug_types
comdat sections.
Recommitted as r197210 with a fix to dumping and reverted as r197211
because I was a bit gun shy and thought I saw a failure that turned out
to be unrelated.
So here we go - once more with feeling! \o/
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197275 91177308-0d34-0410-b5e6-96231b3b80d8
This commit does not complete the type units feature - there are issues
around fission support (skeletal type units, pubtypes/pubnames) and
hashing of some types including those containing references to types in
other type units.
Originally committed as r197073 and reverted in r197079.
Recommitted as r197197 to reproduce the failure and reverted as r197199
Turns out there was unstable ordering in the type unit dumping code.
Fixed by using MapVector in DWARFContext to store the debug_types
comdat sections.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197210 91177308-0d34-0410-b5e6-96231b3b80d8
This commit does not complete the type units feature - there are issues
around fission support (skeletal type units, pubtypes/pubnames) and
hashing of some types including those containing references to types in
other type units.
Originally committed as r197073 and reverted in r197079.
This commit originally got jumbled up with another build-breaking commit
and I can't find the failures I thought this caused anymore.
Recommitting to hopefully get some clean buildbot results to work from.
I have a sneaking suspicion there's unstable output in the comdat group
output of MCStreamer...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197197 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r197073.
The test seems to be failing on some buildbots for unknown reasons.
Reverting until I can figure that out. If anyone's got a reproduction
(.s and .o together would be great) - I'd really appreciate it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197079 91177308-0d34-0410-b5e6-96231b3b80d8
This commit does not complete the type units feature - there are issues
around fission support (skeletal type units, pubtypes/pubnames) and
hashing of some types including those containing references to types in
other type units.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197073 91177308-0d34-0410-b5e6-96231b3b80d8
This re-lands commit r196876, which was reverted in r196879.
The tests have been fixed to pass on platforms with a stack alignment
larger than 4.
Update to clang side tests will land shortly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196939 91177308-0d34-0410-b5e6-96231b3b80d8
For stack frames requiring realignment, three pointers may be needed:
- ebp to address incoming arguments
- esi (could be any callee-saved register) to address locals
- esp to address outgoing arguments
We would use esi unconditionally without verifying that it did not
conflict with inline assembly.
This change doesn't do the verification, it simply emits a fatal error
on functions that use stack realignment, dynamic SP adjustments, and
inline assembly.
Because stack realignment is common on Windows, we also no longer assume
that MS inline assembly clobbers esp. Instead, we analyze the inline
instructions for implicit definitions and check if esp is there. If so,
we require the use of a base pointer and consider it in the condition
above.
Mostly fixes PR16830, but we could try harder to find a non-conflicting
base pointer.
Reviewers: sunfish
Differential Revision: http://llvm-reviews.chandlerc.com/D1317
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196876 91177308-0d34-0410-b5e6-96231b3b80d8
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don’t need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won’t conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196874 91177308-0d34-0410-b5e6-96231b3b80d8
This commit caches the value of the AllowAtInIdentifier variable as
a class variable in AsmLexer. We do this to avoid repeated MAI
queries and string comparisons each time we lex an identifier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196622 91177308-0d34-0410-b5e6-96231b3b80d8
The integrated assembler fails to properly lex arm comments when
they are adjacent to an identifier in the input stream. The reason
is that the arm comment symbol '@' is also used as symbol variant in
other assembly languages so when lexing an identifier it allows the
'@' symbol as part of the identifier.
Example:
$ cat comment.s
foo:
add r0, r0@got to parse this as a comment
$ llvm-mc -triple armv7 comment.s
comment.s:4:18: error: unexpected token in argument list
add r0, r0@got to parse this as a comment
^
This should be parsed as correctly as `add r0, r0`.
This commit modifes the assembly lexer to not include the '@' symbol
in identifiers when lexing for targets that use '@' for comments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196607 91177308-0d34-0410-b5e6-96231b3b80d8
This patch tries to avoid unrelated changes other than fixing a few
hyphen-related ambiguities and contractions in nearby lines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196471 91177308-0d34-0410-b5e6-96231b3b80d8
ELF_Other_Weakref and ELF_Other_ThumbFunc seems to be LLVM
internal ELF symbol flags. These should not be emitted to
object file.
This commit defines ELF_STO_Shift for the target-defined
flags for st_other, and increase the value of
ELF_Other_Shift to 16.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196440 91177308-0d34-0410-b5e6-96231b3b80d8
ARM symbol variants are written with parens instead of @ like this:
.word __GLOBAL_I_a(target1)
This commit adds support for parsing these symbol variants in
expressions. We introduce a new flag to MCAsmInfo that indicates the
parser should use parens to parse the symbol variant. The expression
parser is modified to look for symbol variants using parens instead
of @ when the corresponding MCAsmInfo flag is true.
The MCAsmInfo parens flag is enabled only for ARM on ELF.
By adding this flag to MCAsmInfo, we are able to get rid of
redundant ARM-specific symbol variants and use the generic variants
instead (e.g. VK_GOT instead of VK_ARM_GOT). We use the new
UseParensForSymbolVariant attribute in MCAsmInfo to correctly print
the symbol variants for arm.
To achive this we need to keep a handle to the MCAsmInfo in the
MCSymbolRefExpr class that we can check when printing the symbol
variant.
Updated Tests:
Changed case of symbol variant to match the generic kind.
test/CodeGen/ARM/tls-models.ll
test/CodeGen/ARM/tls1.ll
test/CodeGen/ARM/tls2.ll
test/CodeGen/Thumb2/tls1.ll
test/CodeGen/Thumb2/tls2.ll
PR18080
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196424 91177308-0d34-0410-b5e6-96231b3b80d8
With this patch we use simple names for COMDAT sections (like .text or .bss).
This matches the MSVC behavior.
When merging it is the COMDAT symbol that is used to decide if two sections
should be merged, so there is no point in building a fancy name.
This survived a bootstrap on mingw32.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195798 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes a bug in the assembler that was causing bad code to
be emitted. When switching modes in an assembly file (e.g. arm to
thumb mode) we would always emit the opcode from the original mode.
Consider this small example:
$ cat align.s
.code 16
foo:
add r0, r0
.align 3
add r0, r0
$ llvm-mc -triple armv7-none-linux align.s -filetype=obj -o t.o
$ llvm-objdump -triple thumbv7 -d t.o
Disassembly of section .text:
foo:
0: 00 44 add r0, r0
2: 00 f0 20 e3 blx #4195904
6: 00 00 movs r0, r0
8: 00 44 add r0, r0
This shows that we have actually emitted an arm nop (e320f000)
instead of a thumb nop. Unfortunately, this encodes to a thumb
branch which causes bad things to happen when compiling assembly
code with align directives.
The fix is to notify the ARMAsmBackend when we switch mode. The
MCMachOStreamer was already doing this correctly. This patch makes
the same change for the MCElfStreamer.
There is still a bug in the way nops are emitted for alignment
because the MCAlignment fragment does not store the correct mode.
The ARMAsmBackend will emit nops for the last mode it knew about. In
the example above, we still generate an arm nop if we add a `.code
32` to the end of the file.
PR18019
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195677 91177308-0d34-0410-b5e6-96231b3b80d8
These should not use COMDATs. GNU as uses .bss for .lcomm and section 0 for
.comm.
Given
static int a;
int b;
MSVC puts both in .bss. This patch then puts both .comm and .lcomm on .bss. With
this change we agree with gas on .lcomm, are much closer on .comm and clang-cl
matches msvc on the above example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195654 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195148 91177308-0d34-0410-b5e6-96231b3b80d8
This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file. The memory leaks in this version have been fixed. Thanks
Alexey for pointing them out.
Differential Revision: http://llvm-reviews.chandlerc.com/D2068
Reviewed by Andy
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195064 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r190888, to fix PR17967. The original change wasn't
the right way to get @feat.00 into the object file. The right fix is to
make @feat.00 be a global symbol.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195053 91177308-0d34-0410-b5e6-96231b3b80d8
This change is incorrect. If you delete virtual destructor of both a base class
and a subclass, then the following code:
Base *foo = new Child();
delete foo;
will not cause the destructor for members of Child class. As a result, I observe
plently of memory leaks. Notable examples I investigated are:
ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194997 91177308-0d34-0410-b5e6-96231b3b80d8
There is nothing special about quotes and newlines from the object
file point of view, only the assembler has to worry about expanding
the \n and \".
This patch then removes the special handling from the Mangler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194667 91177308-0d34-0410-b5e6-96231b3b80d8
Accepting quotes is a property of an assembler, not of an object file. For
example, ELF can support any names for sections and symbols, but the gnu
assembler only accepts quotes in some contexts and llvm-mc in a few more.
LLVM should not produce different symbols based on a guess about which assembler
will be reading the code it is printing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194575 91177308-0d34-0410-b5e6-96231b3b80d8
Objective-C data structures.
This is allows tools such as darwin's otool(1) that uses the
LLVM disassembler take a pointer value being loaded by
an instruction and add a comment to what it is being referenced
to make following disassembly of Objective-C programs
more readable.
For example disassembling the Mac OS X TextEdit app one
will see comments like the following:
movq 0x20684(%rip), %rsi ## Objc selector ref: standardUserDefaults
movq 0x21985(%rip), %rdi ## Objc class ref: _OBJC_CLASS_$_NSUserDefaults
movq 0x1d156(%rip), %r14 ## Objc message: +[NSUserDefaults standardUserDefaults]
leaq 0x23615(%rip), %rdx ## Objc cfstring ref: @"SelectLinePanel"
callq 0x10001386c ## Objc message: -[[%rdi super] initWithWindowNibName:]
These diffs also include putting quotes around C strings
in literal pools and uses "symbol address" in the comment
when adding a symbol name to the comment to tell these
types of references apart:
leaq 0x4f(%rip), %rax ## literal pool for: "Hello world"
movq 0x1c3ea(%rip), %rax ## literal pool symbol address: ___stack_chk_guard
Of course the easy changes are in the LLVM disassembler and
the hard work is up to the implementer of the SymbolLookUp()
call back.
rdar://10602439
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193833 91177308-0d34-0410-b5e6-96231b3b80d8
ELF. They can overlap with the other symbols, e.g. if a source file
"foo.c" contains a function "foo" with a static variable "c".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193569 91177308-0d34-0410-b5e6-96231b3b80d8
When assembling, a .thumb_func directive is supposed to be applicable to the
next symbol definition, even if there are intervening directives. We were
racing ahead to try and find it, and this commit should fix the issue.
Patch by Gabor Ballabas
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193403 91177308-0d34-0410-b5e6-96231b3b80d8
Also improve the implementation of EmitRawText(Twine) so it doesn't
bother using the SmallString buffer if the Twine is a simple StringRef
anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193378 91177308-0d34-0410-b5e6-96231b3b80d8
This is another (final?) stab at making us able to parse our own asm output
on Windows.
Symbols on Windows often contain @'s and ?'s in their names. Our asm parser
didn't like this. ?'s were not allowed, and @'s were intepreted as trying to
reference PLT/GOT/etc.
We can't just add quotes around the bad names, since e.g. for MinGW, we use gas
to assemble, and it doesn't like quotes in some places (notably in .def
directives).
This commit makes us allow ?'s in symbol names, and @'s in symbol names for MS
assembly.
Differential Revision: http://llvm-reviews.chandlerc.com/D1978
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193000 91177308-0d34-0410-b5e6-96231b3b80d8
This caused the clang-native-mingw32-win7 buildbot to break.
The assembler was complaining about the following lines that were showing up
in the asm for CrashRecoveryContext.cpp:
movl $"__ZL16ExceptionHandlerP19_EXCEPTION_POINTERS@4", 4(%eax)
calll "_AddVectoredExceptionHandler@8"
.def "__ZL16ExceptionHandlerP19_EXCEPTION_POINTERS@4";
"__ZL16ExceptionHandlerP19_EXCEPTION_POINTERS@4":
calll "_RemoveVectoredExceptionHandler@4"
Reverting for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192940 91177308-0d34-0410-b5e6-96231b3b80d8
The reason this got reverted was that the @feat.00 symbol which was emitted
for every TU became quoted, and on cygwin/mingw we use the gas assembler which
couldn't handle the quotes.
This commit fixes the problem by only emitting @feat.00 for win32, where we use
clang -cc1as to assemble. gas would just drop this symbol anyway, so there is no
loss there.
With @feat.00 gone, there shouldn't be quoted symbols showing up on cygwin since
it uses the Itanium ABI, which doesn't put these funny characters in symbols.
> Because of win32 mangling, we produce symbol and section names with
> funny characters in them, most notably @ characters.
>
> MC would choke on trying to parse its own assembly output. This patch addresses
> that by:
>
> - Making @ trigger quoting of symbol names
> - Also quote section names in the same way
> - Just parse section names like other identifiers (to allow for quotes)
> - Don't assume @ signifies a symbol variant if it is in a string.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192859 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes a small mistake in MCDataAtom::addData() where it doesn't ever
call remap():
- if (Data.size() > Begin - End - 1)
+ if (Data.size() > End + 1 - Begin)
remap(Begin, End + 1);
This is currently not visible because of another bug is the disassembler, so
the patch includes a unit test.
Patch by Stephen Checkoway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192823 91177308-0d34-0410-b5e6-96231b3b80d8
GNU AS didn't like quotes in symbol names.
Error: junk at end of line, first unrecognized character is `"'
.def "@feat.00";
"@feat.00" = 1
Reproduced on Cygwin's 2.23.52.20130309 and mingw32's 2.20.1.20100303.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192775 91177308-0d34-0410-b5e6-96231b3b80d8
Because of win32 mangling, we produce symbol and section names with
funny characters in them, most notably @ characters.
MC would choke on trying to parse its own assembly output. This patch addresses
that by:
- Making @ trigger quoting of symbol names
- Also quote section names in the same way
- Just parse section names like other identifiers (to allow for quotes)
- Don't assume @ signifies a symbol variant if it is in a string.
Differential Revision: http://llvm-reviews.chandlerc.com/D1945
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192758 91177308-0d34-0410-b5e6-96231b3b80d8
This can happen when processing command line arguments, which
are often stored as std::string's and later turned into
StringRef's via std::string::data(). Unfortunately this
is not guaranteed to return a null-terminated string
until C++11, causing breakage on platforms that don't do this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192558 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes an old FIXME by creating a MCTargetStreamer interface
and moving the target specific functions for ARM, Mips and PPC to it.
The ARM streamer is still declared in a common place because it is
used from lib/CodeGen/ARMException.cpp, but the Mips and PPC are
completely hidden in the corresponding Target directories.
I will send an email to llvmdev with instructions on how to use this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192181 91177308-0d34-0410-b5e6-96231b3b80d8
When MC was first added, targets could use hasRawTextSupport to keep features
working before they were added to the MC interface.
The design goal of MC is to provide an uniform api for printing assembly and
object files. Short of relaxations and other corner cases, a object file is
just another representation of the assembly.
It was never the intention that targets would keep doing things like
if (hasRawTextSupport())
Set flags in one way.
else
Set flags in another way.
When they do that they create two code paths and the object file is no longer
just another representation of the assembly. This also then requires testing
with llc -filetype=obj, which is extremelly brittle.
This patch removes some of these hacks by replacing them with smaller ones.
The ARM flag setting is trivial, so I just moved it to the constructor. For
Mips, the patch adds two temporary hack directives that allow the assembly
to represent the same things as the object file was already able to.
The hope is that the mips developers will replace the hack directives with
the same ones that gas uses and drop the -print-hack-directives flag.
I will also try to implement a target streamer interface, so that we can
move this out of the common code.
In summary, for any new work, two rules of the thumb are
* Don't use "llc -filetype=obj" in tests.
* Don't add calls to hasRawTextSupport.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192035 91177308-0d34-0410-b5e6-96231b3b80d8
This patch handles LLVM standalone assembler (llvm-mc) ELF flag setting based on input file
directive processing.
Mips assembly requires processing inline directives that directly and
indirectly affect the output ELF header flags. This patch handles one
".abicalls".
To process these directives we are following the model the code generator
uses by storing state in a container as we go through processing and when
we detect the end of input file processing, AsmParser is notified and we
update the ELF header flags through a MipsELFStreamer method with a call from
MCTargetAsmParser::emitEndOfAsmFile(MCStreamer &OutStreamer).
This patch will allow other targets the same functionality.
Jack
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191982 91177308-0d34-0410-b5e6-96231b3b80d8
itinerary model in case the target does not supply a scheduling model.
By doing this, targets like cortex-a8 can benefit from the latency printing
feature added in r191859.
This part of <rdar://problem/14687488>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191916 91177308-0d34-0410-b5e6-96231b3b80d8
classes that are marked as Variant as those require an MI to pass to
SubTargetInfo::resolveSchedClass.
This is part of <rdar://problem/14687488>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191864 91177308-0d34-0410-b5e6-96231b3b80d8
disassembled output alongside the instructions.
E.g., on a vector shuffle operation with a memory operand, disassembled
outputs are:
* Without the option:
vpshufd $-0x79, (%rsp), %xmm0
* With the option:
vpshufd $-0x79, (%rsp), %xmm0 ## Latency: 5
The printed latency is extracted from the schedule model available in the
disassembler context. Thus, this option has no effect if there is not a
scheduling model for the target.
This boils down to one may need to specify the CPU string, so that this
option could have an effect.
Note: Latency < 2 are not printed.
This part of <rdar://problem/14687488>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191859 91177308-0d34-0410-b5e6-96231b3b80d8
comments issued with verbose assembly.
E.g., on a vector shuffle operation, disassembled output are:
* Without the option:
vpshufd $-0x79, (%rsp), %xmm0
* With the option:
vpshufd $-0x79, (%rsp), %xmm0 ## xmm0 = mem[3,1,0,2]
This part of <rdar://problem/14687488>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191799 91177308-0d34-0410-b5e6-96231b3b80d8
that each comment ends with a newline to match the definition in the header
file.
This is part of <rdar://problem/14687488>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191787 91177308-0d34-0410-b5e6-96231b3b80d8
CFE produces it to indicate artificial locations.
c.f.: DWARF standard, Table 6.2:
line -- An unsigned integer indicating a source line number. Lines are numbered beginning at 1. The compiler may emit the value 0 in cases where an instruction cannot be attributed to any source line.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191471 91177308-0d34-0410-b5e6-96231b3b80d8
The binutils assembler supports a mode called DOLLAR_DOT which treats
the dollar sign token as a reference to the current program counter if
the dollar sign doesn't precede a constant or identifier.
This commit adds a new MCAsmInfo flag stating whether or not a given
target supports this interpretation of the dollar sign token; by
default, this flag is not enabled.
Further, enable this flag for PPC. The system assembler for AIX and
binutils both support using the dollar sign in this manner.
This fixes PR17353.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191368 91177308-0d34-0410-b5e6-96231b3b80d8
The size of common symbols is now tracked correctly, so they can be listed in the arange section without needing knowledge of other following symbols.
.comm (and .lcomm) do not indicate to the system assembler any particular section to use, so we have to treat them as having no section.
Test case update to account for this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191210 91177308-0d34-0410-b5e6-96231b3b80d8
This makes using array_pod_sort significantly safer. The implementation relies
on function pointer casting but that should be safe as we're dealing with void*
here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191175 91177308-0d34-0410-b5e6-96231b3b80d8
Allow binutils .type and .section directives to take the following
forms:
- @<type>
- %<type>
- "<type>"
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191134 91177308-0d34-0410-b5e6-96231b3b80d8
Clean up some simple code quality issues. Bring internal naming
conventions up to current standard, fix inconsistent formatting, and
tidy up a couple of odd contructs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191117 91177308-0d34-0410-b5e6-96231b3b80d8