| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 203211
|
|
|
|
|
|
|
| |
This patch tries to avoid unrelated changes other than fixing a few
hyphen-related ambiguities and contractions in nearby lines.
llvm-svn: 196471
|
|
|
|
|
|
| |
Give the symbol's name and disengage the enchanced crash reporting.
llvm-svn: 191344
|
|
|
|
|
|
| |
magic numbers
llvm-svn: 190013
|
|
|
|
| |
llvm-svn: 189728
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with a debug build) with this buggy .indirect_symbol directive usage:
% cat test.s
x: .indirect_symbol _y
The assertion is because it is trying to get the symbol index for the
symbol _y when it is writing out the indirect symbol table. This line of
code in MachObjectWriter::WriteObject() :
Write32(Asm.getSymbolData(*it->Symbol).getIndex());
And while there is a symbol _y it does not have any getSymbolData set which
is only done in MachObjectWriter::BindIndirectSymbols() for pointer sections
or stub sections. I added a check and an error in there to catch this in case
something slips through.
But to get a better error the parser should detect when a .indirect_symbol
directive is used and it is not in a pointer section or stub section. To make
that work I moved the handling of the indirect symbol out of the target
independent AsmParser code into the DarwinAsmParser code that can check
for the proper Mach-O section types.
rdar://14825505
llvm-svn: 189497
|
|
|
|
|
|
|
|
|
| |
Object/MachOFormat.h over to Support/MachO.h."
This reverts commits r189319 and r189315. r189315 broke some tests on what I
believe are big-endian platforms.
llvm-svn: 189321
|
|
|
|
| |
llvm-svn: 189315
|
|
|
|
| |
llvm-svn: 173120
|
|
|
|
| |
llvm-svn: 172779
|
|
|
|
|
|
| |
outputting code have a reset, some are not used but were declared for completeness
llvm-svn: 170227
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
|
|
|
| |
llvm-svn: 164181
|
|
|
|
|
|
|
|
|
|
| |
* wrap code blocks in \code ... \endcode;
* refer to parameter names in paragraphs correctly (\arg is not what most
people want -- it starts a new paragraph);
* use \param instead of \arg to document parameters in order to be consistent
with the rest of the codebase.
llvm-svn: 163902
|
|
|
|
|
|
|
|
|
|
|
| |
.set a, b - c + CONSTANT
d = b - c + CONSTANT
Both 'a' and 'd' should be marked as absolute symbols (N_ABS).
rdar://12219394
llvm-svn: 163853
|
|
|
|
| |
llvm-svn: 162362
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use a dedicated MachO load command to annotate data-in-code regions.
This is the same format the linker produces for final executable images,
allowing consistency of representation and use of introspection tools
for both object and executable files.
Data-in-code regions are annotated via ".data_region"/".end_data_region"
directive pairs, with an optional region type.
data_region_directive := ".data_region" { region_type }
region_type := "jt8" | "jt16" | "jt32" | "jta32"
end_data_region_directive := ".end_data_region"
The previous handling of ARM-style "$d.*" labels was broken and has
been removed. Specifically, it didn't handle ARM vs. Thumb mode when
marking the end of the section.
rdar://11459456
llvm-svn: 157062
|
|
|
|
| |
llvm-svn: 153429
|
|
|
|
|
|
|
|
| |
When not using subsections via symbols, the assembler can resolve
symbol differences (including pcrel references) to non-local
labels at assembly time, not just those in the same atom.
llvm-svn: 148865
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the two fragments are in the same Atom, then the difference
expression is resolvable at compile time. Previously we were checking
that they were in the same fragment, but that breaks down in the
presence of instruction relaxation which has multiple fragments in the
same atom.
rdar://10711829
llvm-svn: 148423
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the non-local symbol in the expression is in the same fragment
as the second symbol, the assembler can still evaluate the expression
without needing a relocation.
For example, on ARM:
_foo:
ldr lr, (_foo - 4)
rdar://10348687
llvm-svn: 148341
|
|
|
|
|
|
|
|
| |
When the file isn't being built with subsections-via-symbols, symbol
differences involving non-local symbols can be resolved more aggressively.
Needed for gas compatibility.
llvm-svn: 146054
|
|
|
|
| |
llvm-svn: 145878
|
|
|
|
|
|
| |
per http://llvm.org/docs/CodingStandards.html#ll_naming
llvm-svn: 145873
|
|
|
|
| |
llvm-svn: 139325
|
|
|
|
|
|
| |
without a base symbol that must not have a relocation entry.
llvm-svn: 139316
|
|
|
|
|
|
| |
instead. This matches what as does.
llvm-svn: 137414
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Assigned symbol addresses get truncated to 32-bits, even on 64-bit platforms.
That's obviously bogus.
For example,
.globl _foo
.equ _foo, 0x987654321ULL
rdar://9922863
llvm-svn: 137158
|
|
|
|
|
|
| |
createMCAsmBackend.
llvm-svn: 136010
|
|
|
|
|
|
| |
they belong.
llvm-svn: 135833
|
|
|
|
|
|
|
|
|
| |
Move the target-specific RecordRelocation logic out of the generic MC
MachObjectWriter and into the target-specific object writers. This allows
nuking quite a bit of target knowledge from the supposedly target-independent
bits in lib/MC.
llvm-svn: 133844
|
|
|
|
| |
llvm-svn: 133815
|
|
|
|
|
|
| |
rdar://9667872
llvm-svn: 133808
|
|
|
|
| |
llvm-svn: 133770
|
|
|
|
| |
llvm-svn: 133668
|
|
|
|
|
|
|
| |
line with LLVM's general coding style.
No functionality change.
llvm-svn: 133645
|
|
|
|
| |
llvm-svn: 130522
|
|
|
|
| |
llvm-svn: 130520
|
|
|
|
|
|
| |
assuming they are present in a fragment.
llvm-svn: 130519
|
|
|
|
|
|
| |
Luis Felipe Strano Moraes!
llvm-svn: 129558
|
|
|
|
|
|
| |
BLX, rather than a 2-byte instruction like B.
llvm-svn: 128169
|
|
|
|
|
|
|
| |
This fixes kimwitu++, bullet, and tramp3dv4 with the ARM integrated assembler.
Fixes <rdar://problem/9165738>.
llvm-svn: 128117
|
|
|
|
|
|
| |
MCFixupKind. This is the same technique that is used elsewhere in MC.
llvm-svn: 127676
|
|
|
|
|
|
| |
Patch by Erik Olofsson!
llvm-svn: 126796
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(yes, this is different from R_ARM_CALL)
- Adds a new method getARMBranchTargetOpValue() which handles the
necessary distinction between the conditional and unconditional br/bl
needed for ARM/ELF
At least for ARM mode, the needed fixup for conditional versus unconditional
br/bl is identical, but the ARM docs and existing ARM tools expect this
reloc type...
Added a few FIXME's for future naming fixups in ARMInstrInfo.td
llvm-svn: 124895
|
|
|
|
| |
llvm-svn: 124645
|
|
|
|
|
|
|
|
| |
- Fixed :upper16: fix up routine. It should be shifting down the top 16 bits first.
- Added support for Thumb2 :lower16: and :upper16: fix up.
- Added :upper16: and :lower16: relocation support to mach-o object writer.
llvm-svn: 123424
|
|
|
|
| |
llvm-svn: 122583
|
|
|
|
|
|
| |
have a single point where targets test if a relocation is needed.
llvm-svn: 122549
|
|
|
|
| |
llvm-svn: 122547
|