Variadic functions have an unspecified parameter tag after the last
argument. In IR this is represented as an unspecified parameter in the
subroutine type.
Paired commit with CFE r202185.
rdar://problem/13690847
This re-applies r202184 + a bugfix in DwarfDebug's argument handling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202188 91177308-0d34-0410-b5e6-96231b3b80d8
Variadic functions have an unspecified parameter tag after the last
argument. In IR this is represented as an unspecified parameter in the
subroutine type.
Paired commit with CFE.
rdar://problem/13690847
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202184 91177308-0d34-0410-b5e6-96231b3b80d8
passing down an AsmPrinter instance so we could compute the size of
the block which could be target specific. All of the test cases in
the unittest don't have any target specific data so we can use a NULL
AsmPrinter there. This also depends upon block data being added as
integers.
We can now hash the entire fission-cu.ll compile unit so turn the
flag on there with the hash value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201752 91177308-0d34-0410-b5e6-96231b3b80d8
alongside DIEBlock and replace uses accordingly. Use DW_FORM_exprloc
in DWARF4 and later code. Update testcases.
Adding a DIELoc instead of using extra forms inside DIEBlock so
that we can keep location expressions separate from other uses. No
direct use at the moment, however, it's not a lot of code and
using a separately named class keeps it somewhat more obvious
what's going on in various locations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201481 91177308-0d34-0410-b5e6-96231b3b80d8
This broke in r185459 while TLS support was being generalized to handle
non-symbol TLS representations.
I thought about/tried having an enum rather than a bool to track the
TLS-ness of the address table entry, but namespaces and naming seemed
more hassle than it was worth for only one caller that needed to specify
this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201469 91177308-0d34-0410-b5e6-96231b3b80d8
Type units will share the statement list of their defining compile unit.
This is a tradeoff that reduces .o debug info size at the cost of some
linked debug info size (since the contents of those string tables won't
be deduplicated along with the type unit) which seems right for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201445 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
Since I just discovered this while poking at other things, here's the
test case so I have it to come back to later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201267 91177308-0d34-0410-b5e6-96231b3b80d8
There's still one piece missing here, which is adding the
DW_AT_stmt_list to the type unit that refer's to the compile unit's line
table. Working on that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201198 91177308-0d34-0410-b5e6-96231b3b80d8
Debug info: Emit values in subregisters that do not have a separate
DWARF register number by emitting a super-register + DW_OP_bit_piece.
This is necessary because on x86_64, there are no DWARF register numbers
for i386-style subregisters.
Fixes a bunch of FIXMEs.
rdar://problem/16015314
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201190 91177308-0d34-0410-b5e6-96231b3b80d8
This comes up in empty files or files containing #file directives that
never reference the actual source file name. Came up in a small test of
line tables I was playing with.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201187 91177308-0d34-0410-b5e6-96231b3b80d8
DWARF register number by emitting a super-register + DW_OP_bit_piece.
This is necessary because on x86_64, there are no DWARF register numbers
for i386-style subregisters.
Fixes a bunch of FIXMEs.
rdar://problem/16015314
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201180 91177308-0d34-0410-b5e6-96231b3b80d8
A bunch of test cases needed to be cleaned up for this, many my fault -
when implementid imported modules I updated test cases by simply
duplicating the prior metadata field - which wasn't always the empty
metadata entry.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200731 91177308-0d34-0410-b5e6-96231b3b80d8
This ensures DWARF consumers don't confuse these references for
definitions. I'd argue it might be nice to improve debuggers so we don't
need this, but it's just one field in an abbreviation anyway - so it
doesn't seem worth the fight.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200569 91177308-0d34-0410-b5e6-96231b3b80d8
are relative to in the compile unit. Currently let's just use 0...
Thanks to Greg Clayton for the catch!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200425 91177308-0d34-0410-b5e6-96231b3b80d8
module since there's no range guarantee that we could make given
output order. This also fixes up the testcases that have multiple
CUs to have the correct range offset.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200422 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
compile unit. Make these relocations on the platforms that need
relocations and add a routine to ensure that we don't put the
addresses in an offset table for split dwarf.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199990 91177308-0d34-0410-b5e6-96231b3b80d8
optional DWARF sections, so compiling with -g does not result in
different code being generated for PC-relative loads.
This is reapplying a diet r197922 (__TEXT-only).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199681 91177308-0d34-0410-b5e6-96231b3b80d8
Cut back on the cargo cult. The order of __DATA sections doesn't affect
generated code.
This reverts commit r197922.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199680 91177308-0d34-0410-b5e6-96231b3b80d8
