bcm5719-llvm/llvm/test/DebugInfo/cu-line-tables.ll, branch meklort-10.0.1Project Ortega BCM5719 LLVMhttps://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.12014-09-19T04:30:36+00:00Omit all the extra static attributes on subprograms in -gmlt2014-09-19T04:30:36+00:00David Blaikiedblaikie@gmail.com2014-09-19T04:30:36+00:00urn:sha1:73b65d236cb931877aa3f8a196068dcbeb9b57e9
This omission will be done in a fancier manner once we're dealing with
"put gmlt in the skeleton CUs under fission" - it'll have to be
conditional on the kind of CU we're emitting into (skeleton or gmlt).
llvm-svn: 218098
DebugInfo: Make a test more portable2014-08-07T03:47:28+00:00Justin Bognermail@justinbogner.com2014-08-07T03:47:28+00:00urn:sha1:989cbc9058c9d001da6367cf28e3184eaaf03a42
mach-o doesn't like sections without segments, and elf is perfectly
happy with commas in section names, so use a Darwin-like section name.
Suggestion by Eric Christopher.
llvm-svn: 215052
DebugInfo: Fix ranges+gmlt test case to actually exercise the gmlt situation.2014-08-06T18:24:19+00:00David Blaikiedblaikie@gmail.com2014-08-06T18:24:19+00:00urn:sha1:6e9477af8c935844ad65a3cf59f2c23faa861dca
Originally this test case tested the specified behavior (that -gmlt
would not produce DW_AT_ranges and that when no CU DW_AT_ranges were
produced, no debug_ranges section (not even an empty list) would be
produced) but then the ranges emission code was improved not to create
ranges of a single element (instead favoring high_pc/low_pc) and so this
test case no longer exercised the -gmlt portion of the behavior.
This caused me some confusion when reading the comments and trying to
update this test case for future changes to -gmlt. I've made this test
resilient to those changes (by using the {{DW_TAG|NULL}} pattern to
block the end of the attribute search at the end of the CU's attribute
list without mandating that it must (or must not) be followed by another
tag (the future changes to -gmlt should produce no subprograms in this
CU))
Fix the test case to have two functions in distinct sections to force
the use of DW_AT_ranges.
llvm-svn: 214985
DebugInfo: Make gmlt debug info more gmlt-like by removing variables.2014-05-12T21:33:03+00:00David Blaikiedblaikie@gmail.com2014-05-12T21:33:03+00:00urn:sha1:e323670892d25d76435d831d73c3837ed8890213
For some impending improvements to debug info, LLVM will start assuming
that when the CU specifies llvm::DIBuilder::LineTablesOnly, the IR for
functions described by that CU will not include variables, types, etc.
(might be worth having some test coverage for GMLT + non-GMLT CUs,
especially with non-GMLT functions inlined into GMLT CU functions)
llvm-svn: 208634
Remove the -generate-dwarf-cu-ranges flag.2014-03-14T20:53:43+00:00Eric Christopherechristo@gmail.com2014-03-14T20:53:43+00:00urn:sha1:3a70d0083fbd9f289223197ca0fc7918d3d95531
Rewrite a couple of testcases to cover areas that would be normally
by turning it on into testcases that will follow the logic.
llvm-svn: 203968
DebugInfo: Omit pubnames/pubtypes when compiling with -gmlt2014-03-12T03:34:38+00:00David Blaikiedblaikie@gmail.com2014-03-12T03:34:38+00:00urn:sha1:adbea1ef9f56712dc050bd68d8026de643913826
llvm-svn: 203634
Don't emit anything into the debug_ranges section if we aren't emitting2014-02-27T07:44:45+00:00Eric Christopherechristo@gmail.com2014-02-27T07:44:45+00:00urn:sha1:a9a1d276773a85c501213bfe3ed8dfe511d8a7bd
any ranges - this includes CU ranges where we were previously emitting an
end list marker even if we didn't have a list.
Testcase includes a test for line table only code emission as the problem
was noticed while writing this test.
llvm-svn: 202357