1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-20 19:42:54 +02:00
Commit Graph

295 Commits

Author SHA1 Message Date
David Blaikie
13ae175ea5 Cleanup some unused or trivial functions in DwarfCompileUnit
llvm-svn: 221164
2014-11-03 17:10:38 +00:00
David Blaikie
cc391f34cf Add DwarfUnit::isDwoUnit and use it to generalize string creation
Currently we only need to emit skeleton strings into the CU header and
we do this by explicitly calling "addLocalString". With gmlt-in-fission,
we'll be emitting a bunch of other strings from other codepaths where
it's not statically known that these strings will be local or not.

Introduce a virtual function to indicate whether this unit is a DWO unit
or not (I'm not sure if we have a good term for this, the
opposite/alternative to 'skeleton' unit) and use that to generalize the
string emission logic so that strings can be correctly emitted in both
the skeleton and dwo unit when in split dwarf mode.

And to demonstrate that this works, switch the existing special callers
of addLocalString in the skeleton builder to addString - and they still
work. Yay.

llvm-svn: 221094
2014-11-02 08:51:37 +00:00
David Blaikie
7319643a43 Remove the last mention of LineTablesOnly from DwarfUnit, sinking it into DwarfCompileUnit
This is a useful distinction/invariant/delination to make because
LineTablesOnly mode is never relevant to type units, so it's clear that
we're not doing weird line-tables-only-with-types by making this API
choice.

It also lays the foundations nicely for adding gmlt-like data to fission
skeleton CUs while limiting the effects to CUs and not TUs.

llvm-svn: 221093
2014-11-02 08:18:06 +00:00
David Blaikie
bb5b8ec235 Sink DwarfUnit::applySubprogramAttributesToDefinition into DwarfCompileUnit
llvm-svn: 221092
2014-11-02 08:09:09 +00:00
David Blaikie
17a3519bc0 Sink DwarfUnit::addExpr into DwarfCompileUnit
llvm-svn: 221090
2014-11-02 07:11:55 +00:00
David Blaikie
ec951ad31c Fix the build from the last commit
llvm-svn: 221089
2014-11-02 07:08:12 +00:00
David Blaikie
96c3f13e27 Sink DwarfUnit::applyVariableAttributes into DwarfCompileUnit
llvm-svn: 221088
2014-11-02 07:06:51 +00:00
David Blaikie
abebe0162c Sink DwarfUnit::addLocationList down into DwarfCompileUnit
llvm-svn: 221087
2014-11-02 07:03:19 +00:00
David Blaikie
aadd810834 Sink DwarfUnit::addComplexAddress down into DwarfCompileUnit
llvm-svn: 221086
2014-11-02 06:58:44 +00:00
David Blaikie
d6a9a46935 Push DwarfUnit::addAddress down into DwarfCompileUnit
llvm-svn: 221085
2014-11-02 06:46:40 +00:00
David Blaikie
33c9b0d67b Sink DwarfUnit::addVariableAddress into DwarfCompileUnit since type units don't have variables
llvm-svn: 221084
2014-11-02 06:37:23 +00:00
David Blaikie
9a1d2d413e DebugInfo: Sink accelerator table lists down (GlobalNames/Types) into DwarfCompileUnit
llvm-svn: 221083
2014-11-02 06:16:39 +00:00
David Blaikie
3761128594 Be sure to initialize DwarfCompileUnit::LabelBegin now that it may be skipped in initSection
llvm-svn: 221079
2014-11-02 02:40:26 +00:00
David Blaikie
530359d196 Don't bother creating LabelBegin for .dwo units
This would help catch cases where we might otherwise try to reference a
dwo CU label, which would be weird - because without relocations in the
dwo file it's not generally meaningful to talk about the CU offsets
there (or, if it is, we can do so in absolute terms without using a
relocation to compute it).

llvm-svn: 221078
2014-11-02 02:26:24 +00:00
David Blaikie
44f17e492d Sink dwarf unit length emission down into DwarfUnit::emitHeader
This allows the CU label to be emitted only for compile units, as
they're the only ones that need it (so they can be referenced from
pubnames)

llvm-svn: 221072
2014-11-01 23:59:23 +00:00
David Blaikie
1c7f7fe885 Sink DwarfUnit::Skeleton down into DwarfCompileUnit
Type units no longer have skeletons and it's misleading to be able to
query for a type unit's skeleton (it might incorrectly lead one to
conclude that if a unit doesn't have a skeleton it's not in a .dwo
file... ).

llvm-svn: 221055
2014-11-01 18:18:07 +00:00
David Blaikie
eddf5043ac Sink DwarfDebug::AbstractSPDies down into DwarfFile
This is the first big step to allowing gmlt-like inline scope
information in the skeleton CU. While this commit doesn't change the
functionality, it's only a small step to call
"constructAbstractSubprogramDIE" on both the InfoHolder and the
SkeletonHolder (when in use) and that will at least create the abstract
SP dies in that case, though still not creating the other subprograms.

llvm-svn: 221051
2014-11-01 17:21:26 +00:00
David Blaikie
1e29b40b41 Sink some of DwarfDebug::collectDeadVariables down into DwarfCompileUnit.
llvm-svn: 221010
2014-10-31 22:30:30 +00:00
David Blaikie
da34a7bac5 Sink most of DwarfDebug::constructAbstractSubprogramScopeDIE into DwarfCompileUnit
llvm-svn: 221005
2014-10-31 21:57:02 +00:00
Frederic Riss
1a2ce34071 Sink DwarfUnit::constructImportedEntityDIE into DwarfCompileUnit.
So that it has access to getOrCreateGlobalVariableDIE. If we ever support
decsribing using directive in C++ classes (thus requiring support in type
units), it will certainly use another mechanism anyway.

Differential Revision: http://reviews.llvm.org/D5975

llvm-svn: 220594
2014-10-24 21:31:09 +00:00
David Blaikie
21ab861fa1 DebugInfo: Sink DwarfDebug::ScopeVariables down into DwarfFile
(part of refactoring to allow subprogram emission in both the skeleton
and main units to enable -gmlt-like data to be included in the skeleton
for live inlined backtracing purposes)

llvm-svn: 220578
2014-10-24 17:57:34 +00:00
David Blaikie
92e415962d DebugInfo: Remove DwarfDebug::CurrentFnArguments since we have to handle argument ordering of other arguments (abstract arguments) in the same way and already have code for that too.
While refactoring this code I was confused by both the name I had
introduced (addNonArgumentVariable... but it has all this logic to
handle argument numbering and keep things in order?) and by the
redundancy. Seems when I fixed the misordered inlined argument handling,
I didn't realize it was mostly redundant with the argument ordering code
(which I may've also written, I'm not sure). So let's just rely on the
more general case.

The only oddity in output this produces is that it means when we emit
all the variables for the current function, we don't track when we've
finished the argument variables and are about to start the local
variables and insert DW_AT_unspecified_parameters (for varargs
functions) there. Instead it ends up after the local variables, scopes,
etc. But this isn't invalid and doesn't cause DWARF consumers problems
that I know of... so we'll just go with that because it makes the code
nice & simple.

(though, let's see what the buildbots have to say about this - *crosses
fingers*)

There will be some cleanup commits to follow to remove the now trivial
wrappers, etc.

llvm-svn: 220527
2014-10-23 22:27:50 +00:00
David Blaikie
1e1e6fb31c DebugInfo: Simplify/tidy/correct global variable decl/def emission handling.
This fixes a bug (introduced by fixing the IR emitted from Clang where
the definition of a static member would be scoped within the class,
rather than within its lexical decl context) where the definition of a
static variable would be placed inside a class.

It also improves source fidelity by scoping static class member
definitions inside the lexical decl context in which tehy are written
(eg: namespace n { class foo { static int i; } int foo::i; } - the
definition of 'i' will be within the namespace 'n' in the DWARF output
now).

Lastly, and the original goal, this reduces debug info size slightly
(and makes debug info easier to read, etc) by placing the definitions of
non-member global variables within their namespace, rather than using a
separate namespace-scoped declaration along with a definition at global
scope.

Based on patches and discussion with Frédéric.

llvm-svn: 220497
2014-10-23 19:12:43 +00:00
David Blaikie
6a3e82d728 Sink the per-CU part of DwarfDebug::finishSubprogramDefinitions into DwarfCompileUnit.
llvm-svn: 219477
2014-10-10 06:39:29 +00:00
David Blaikie
39b2185feb Sink most of DwarfDebug::constructAbstractSubprogramScopeDIE down into DwarfCompileUnit.
llvm-svn: 219476
2014-10-10 06:39:26 +00:00
David Blaikie
5cc331ae79 Sink DwarfDebug::createAndAddScopeChildren down into DwarfCompileUnit.
llvm-svn: 219437
2014-10-09 20:26:15 +00:00
David Blaikie
6e8ade1095 Sink DwarfDebug::constructSubprogramScopeDIE down into DwarfCompileUnit
llvm-svn: 219436
2014-10-09 20:21:36 +00:00
David Blaikie
477f8cb9ba Sink DwarfDebug::createScopeChildrenDIE down into DwarfCompileUnit.
llvm-svn: 219422
2014-10-09 18:24:28 +00:00
David Blaikie
c7aba518d5 Sink DwarfDebug.cpp::constructVariableDIE into DwarfCompileUnit.
llvm-svn: 219419
2014-10-09 17:56:39 +00:00
David Blaikie
78c64030db Move DwarfUnit::constructVariableDIE down to DwarfCompileUnit, since it's only needed there.
llvm-svn: 219418
2014-10-09 17:56:36 +00:00
David Blaikie
06c6662b4d Sink DwarfDebug::constructLexicalScopeDIE into DwarfCompileUnit
llvm-svn: 219414
2014-10-09 17:08:42 +00:00
David Blaikie
c49791b401 Missing reformatting
llvm-svn: 219413
2014-10-09 17:08:38 +00:00
David Blaikie
1a81b6999c Sink DwarfDebug::constructInlinedScopeDIE into DwarfCompileUnit
This introduces access to the AbstractSPDies map from DwarfDebug so
DwarfCompileUnit can access it. Eventually this'll sink down to
DwarfFile, but it'll still be generically accessible - not much
encapsulation to provide it. (constructInlinedScopeDIE could stay
further up, in DwarfFile to avoid exposing this - but I don't think
that's particularly better)

llvm-svn: 219411
2014-10-09 16:50:53 +00:00
David Blaikie
4e189e100b Push DwarfDebug::attachRangesOrLowHighPC down into DwarfCompileUnit
llvm-svn: 219372
2014-10-09 00:21:42 +00:00
David Blaikie
f2869de8da Sink DwarfDebug::addScopeRangeList down into DwarfCompileUnit
(& add a few accessors/make a couple of things public for this - it's a
bit of a toss-up, but I think I prefer it this way, keeping some more of
the meaty code down in DwarfCompileUnit - if only to make for smaller
implementation files, etc)

I think we could simplify range handling a bit if we removed the range
lists from each unit and just put a single range list on DwarfDebug,
similar to address pooling.

llvm-svn: 219370
2014-10-09 00:11:39 +00:00
David Blaikie
86080e417c Sink DwarfUnit::addSectionDelta into DwarfCompileUnit, the only place it's needed.
llvm-svn: 219364
2014-10-08 23:30:05 +00:00
David Blaikie
802d562b37 Sink and coalesce DwarfDebug.cpp::addSectionLabel and DwarfUnit::addSectionLabel down into DwarfCompileUnit::addSectionLabel
llvm-svn: 219351
2014-10-08 22:46:27 +00:00
David Blaikie
c48de79313 Push DwarfDebug::constructScopeDIE down into DwarfCompileUnit
One of many steps to generalize subprogram emission to both the DWO and
non-DWO sections (to emit -gmlt-like data under fission). Once the
functions are pushed down into DwarfCompileUnit some of the data
structures will be pushed at least into DwarfFile so that they can be
unique per-file, allowing emission to both files independently.

llvm-svn: 219345
2014-10-08 22:20:02 +00:00
David Blaikie
0eef1c005d Sink DwarfDebug::updateSubprogramScopeDIE into DwarfCompileUnit
This requires exposing some of the current function state from
DwarfDebug. I hope there's not too much of that to expose as I go
through all the functions, but it still seems nicer to expose singular
data down to multiple consumers, than have consumers expose raw mapping
data structures up to DwarfDebug for building subprograms.

Part of a series of refactoring to allow subprograms in both the
skeleton and dwo CUs under Fission.

llvm-svn: 219060
2014-10-04 16:24:00 +00:00
David Blaikie
1f6267c40e Reformatting accidentally left out of r219057
llvm-svn: 219059
2014-10-04 16:00:26 +00:00
David Blaikie
c691131ef4 Sink DwarfDebug::attachLowHighPC into DwarfCompileUnit
One of many things to sink down into DwarfCompileUnit to allow handling
of subprograms in both the skeleton and dwo CU under Fission.

llvm-svn: 219058
2014-10-04 15:58:47 +00:00
David Blaikie
7bf1cb9a67 Move DwarfCompileUnit from DwarfUnit.h to its own header (DwarfCompileUnit.h)
In preparation for sinking all the subprogram emission code down from
DwarfDebug into DwarfCompileUnit, this will avoid bloating
DwarfUnit.h/cpp greatly and make concerns a bit more clear/isolated.

(sinking this handling down is part of the work to handle emitting
minimal subprograms for -gmlt-like data into the skeleton CU under
fission)

llvm-svn: 219057
2014-10-04 15:49:50 +00:00
David Blaikie
c06b6fc581 DebugInfo: Rename DwarfCompileUnit.* to DwarfUnit.* to match their contents.
llvm-svn: 196140
2013-12-02 19:33:15 +00:00
David Blaikie
8f5d7bdcbe DebugInfo: Refactor CompileUnit into a Unit baseclass and CompileUnit/TypeUnit derived classes.
Header/cpp file rename to follow immediately - just splitting out the
commits for ease of review/reading to demonstrate that the renaming
changes are entirely mechanical.

llvm-svn: 196139
2013-12-02 19:33:10 +00:00
David Blaikie
74530dc54e DebugInfo: Type Units: Propagate the correct DW_AT_language into type units.
llvm-svn: 196130
2013-12-02 18:44:29 +00:00
David Blaikie
91268863a6 DebugInfo: Do not include variables only referenced by templates in aranges.
ARanges included even extern variables referenced by pointer non-type
template parameters even though that variable isn't part of this
compilation unit.

llvm-svn: 195895
2013-11-27 23:53:52 +00:00
David Blaikie
2284510f45 DebugInfo: Remove CompileUnit::constructTypeDIEImpl now that it's just a simple wrapper again.
r195698 moved the type unit checking up into getOrCreateTypeDIE so
remove the redundant check and fold the functions back together again.

llvm-svn: 195700
2013-11-26 00:35:04 +00:00
David Blaikie
98277f8277 DebugInfo: Avoid emitting pubtype entries for type DIEs that just indirect to a type unit.
llvm-svn: 195698
2013-11-26 00:22:37 +00:00
David Blaikie
64a5628952 DebugInfo: Pubtypes: Coelesce pubtype registration with accelerator type registration.
It might be possible to eventually use one data structure, but I haven't
looked at the exact criteria used for accelerator tables and pubtypes to
see if there's good reason for the differences between the two or not.

llvm-svn: 195696
2013-11-26 00:15:27 +00:00
Eric Christopher
8b3b8ae8cc In Dwarf 3 (and Dwarf 2) attributes whose value are offsets into a
section use the form DW_FORM_data4 whilst in Dwarf 4 and later they
use the form DW_FORM_sec_offset.

This patch updates the places where such attributes are generated to
use the appropriate form depending on the Dwarf version. The DIE entries
affected have the following tags:
DW_AT_stmt_list, DW_AT_ranges, DW_AT_location, DW_AT_GNU_pubnames,
DW_AT_GNU_pubtypes, DW_AT_GNU_addr_base, DW_AT_GNU_ranges_base

It also adds a hidden command line option "--dwarf-version=<uint>"
to llc which allows the version of Dwarf to be generated to override
what is specified in the metadata; this makes it possible to update
existing tests to check the debugging information generated for both
Dwarf 4 (the default) and Dwarf 3 using the same metadata.

Patch (slightly modified) by Keith Walker!

llvm-svn: 195391
2013-11-21 23:46:41 +00:00