symbol from an assignment. In this case the symbol did not have a fragment so
MCObjectWriter::IsSymbolRefDifferenceFullyResolved() should not have been
calling IsSymbolRefDifferenceFullyResolvedImpl() with a NULL fragment and should
just have returned false in that case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149442 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148865 91177308-0d34-0410-b5e6-96231b3b80d8
If the fixup is out of range for the Thumb1 instruction, relax it
to the Thumb2 encoding instead.
rdar://10711829
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148424 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148341 91177308-0d34-0410-b5e6-96231b3b80d8
assembly source when it generates the TAG_subprogram dwarf debug info for
the labels that have nothing between them as in this bit of assembly source:
% cat ZeroLength.s
_func1:
_func2:
nop
One solution would be to not emit the subsequent labels with the same address
and use the next label with a different address or the end of the section for
the AT_high_pc value of the TAG_subprogram.
Turns out in llvm-mc it is not possible in all cases to determine of two
symbols have the same value at the point we put out the TAG_subprogram dwarf
debug info.
So we will have llvm-mc instead of putting out TAG_subprogram's put out
DW_TAG_label's. And the DW_TAG_label does not have a AT_high_pc value which
avoids the problem.
This commit is only the functional change to make the diffs clear as to what is
really being changed. The next commit will be to clean up the names of such
things like MCGenDwarfSubprogramEntry to something like MCGenDwarfLabelEntry.
rdar://10666925
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147860 91177308-0d34-0410-b5e6-96231b3b80d8
generates the dwarf Compile Unit DIE and a dwarf subprogram DIE for each
non-temporary label.
The next part will be to get the clang driver to enable this when assembling
a .s file. rdar://9275556
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146262 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146054 91177308-0d34-0410-b5e6-96231b3b80d8
it is separating the directory part from the basename of the FileName. Noticed
that this:
.file 1 "dir/foo"
when assembled got the two parts switched. Using the Mac OS X dwarfdump tool
it can be seen easily:
% dwarfdump -a a.out
include_directories[ 1] = 'foo'
Dir Mod Time File Len File Name
---- ---------- ---------- ---------------------------
file_names[ 1] 1 0x00000000 0x00000000 dir
...
Which should be:
...
include_directories[ 1] = 'dir'
Dir Mod Time File Len File Name
---- ---------- ---------- ---------------------------
file_names[ 1] 1 0x00000000 0x00000000 foo
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143521 91177308-0d34-0410-b5e6-96231b3b80d8
.cfi_startproc. e.g. libffi:
$ cat confopt.c
asm (".cfi_startproc\n\t.cfi_endproc");
int main () { return 0; }
Teach MC / dwarf emission to handle these cfi directives which essentially
create an empty frame.
rdar://10017184
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138504 91177308-0d34-0410-b5e6-96231b3b80d8
With this we don't need the EffectiveSize field anymore. Without that field
LayoutFragment only updates offsets and we don't need to invalidate the
current fragment when it is relaxed (only the ones following it).
This is also a very small improvement in the accuracy of the layout info as
we now use the after relaxation size immediately.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121857 91177308-0d34-0410-b5e6-96231b3b80d8
Since we now don't update addresses so early, we might relax a bit more than
we need to. This is simillar to the issue in PR8467.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121856 91177308-0d34-0410-b5e6-96231b3b80d8
as llc + llvm-mc. This time ELF is not changed and I tested that llvm-gcc
bootstrap on darwin10 using darwin9's assembler and linker.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121006 91177308-0d34-0410-b5e6-96231b3b80d8
foo = a - b
.long foo
instead of just
.long a - b
First, on darwin9 64 bits the assembler produces the wrong result. Second,
if "a" is the end of the section all darwin assemblers (9, 10 and mc) will not
consider a - b to be a constant but will if the dummy foo is created.
Split how we handle these cases. The first one is something MC should take care
of. The second one has to be handled by the caller.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120889 91177308-0d34-0410-b5e6-96231b3b80d8
doing that if the target is darwin10 or newer.
This fixes
*) Direct object emission was producing objects without the workaround on
darwin9.
*) Assembly printing was producing objects with the workaround on linux.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120866 91177308-0d34-0410-b5e6-96231b3b80d8
