Re: [Lldb-commits] [PATCH] D45348: Don't return error for settings set .experimental. settings that are absent
On Fri, 6 Apr 2018 at 23:36, Jason Molenda wrote:
>
>
> > On Apr 6, 2018, at 2:07 AM, Pavel Labath via Phabricator <
> revi...@reviews.llvm.org> wrote:
> >
> > labath added inline comments.
> >
> >
> >
> > Comment at:
> packages/Python/lldbsuite/test/settings/TestSettings.py:544-545
> > +# the actual name and via .experimental.
> > +cmdinterp.HandleCommand("settings set target.arg0 first-value",
> result)
> > +self.assertEqual(result.Succeeded(), True)
> > +cmdinterp.HandleCommand("settings show target.arg0", result)
> >
> > Isn't this basically what `self.expect` would do (only with better
> logging and error messages)?
>
>
> Ah, I didn't see that self.expect would allow me to specify whether to
> expect an error return or not. Yes I can write this in terms of
> self.expect more cleanly.
>
> BTW what does the documentation for self.expect in lldbtest.py mean when
> it refers to "golden input"? It uses the phrase a few times and I can't
> figure out what it's talking about. Maybe that term was in the
> documentation from long ago and not a recent addition.
>
>
>
Thanks.
I think the self.expect function predates me, but if I had to guess, I
think here the term "golden" just means the "expected" output. The term
"golden output" is mostly used when comparing large files (usually images)
in tests. I suppose, with some imagination, it could be used checking the
verbatim output of a command is exactly a given string, but when we start
doing substring and regex matches it really becomes inappropriate... Maybe
originally the expect function only supported verbatim matches and this is
a leftover of that?
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D45170: Cleanup DWARFCompileUnit and DWARFUnit in preparation for adding DWARFTypeUnit
I generally try to stay away from debug info, but since I ended up working on the accelerator tables, and I am about to embark on the lldb part of that project I figure I should chime in. I am mostly speaking to the "using llvm libraries for parsing" part of the discussion, I don't have an opinions on the refactorings per se. My plan for getting the new accelerator table support into lldb was to reuse the parser implementation in the llvm's DebugInfo library. The nice thing about it is that it's completely self-contained (it just needs two blobs of data for the .debug_names and .debug_str sections), so I'm hoping that should be fairly easy to accomplish, and land us with the first case of reusing the llvm libraries for debug info parsing. Although starting with the accelerator tables may be a bit upside-down, I think that the second case for using llvm parsers could be to replace the existing apple_names parsers in lldb (again, because the llvm implementations are fairly stand-alone). Now, to get these .debug_names into lldb, I'm going to need to do some refactoring of my own (abstracting the way we index things). I haven't looked at this in more detail yet, but I'm hoping that I can stay clear of the ongoing work on dwz&type units, as all of this happens in SymbolFileDWARF, which you don't seem to touch that much. I'll know more about that once I start doing it. cheers, pavel On Sat, 7 Apr 2018 at 10:04, Jan Kratochvil wrote: > On Sat, 07 Apr 2018 00:52:26 +0200, Greg Clayton wrote: > > Take look at how LLVM does it. I believe my changes mirror that approach. > > LLVM does not support partial units so there is nothing to look at there. > > > > DWARFUnit should be the base class for anything that needs to hand out > DIEs. > > That's OK for partial units. > > > > Any specializations should be inheriting from DWARFUnit, like both > > DWARFCompileUnit and DWARFTypeUnit. > > I see now the source of misunderstanding: > > DWARFCompileUnit = DW_TAG_compile_unit > DWARFTypeUnit = DW_TAG_type_unit > DWARFPartialUnit != DW_TAG_partial_unit > > BTW DW_TAG_imported_unit is importing (="caller") tag, not a unit > (="callee"). > > DW_TAG_partial_unit gets read in (by > DWARFDebugInfo::ParseCompileUnitHeadersIfNeeded) as DWARFCompileUnit > because > there is no quick enough way to find the difference. It would require > reading > the first DIE tag which means to read and decode .debug_abbrev for each > unit > being scanned. > > DWARFPartialUnit is used only as a remapping of DWARFCompileUnit to a new > offset without any new data (there is stored only a new remapped offset > whose > value is only made up internally in LLDB) at the moment someone uses > DW_TAG_imported_unit for it - at that moment we easily know that unit has > to > be DW_TAG_partial_unit. > > Therefore DWARFCompileUnit and DWARFTypeUnit both contain some their own > data. > But DWARFPartialUnit is just a remapping of DWARFCompileUnit (containing > DW_TAG_partial_unit) to a new offset without any new data. Particularly > m_die_array is not in DWARFPartialUnit. > > DWARFTypeUnit can be recognized easily as it is either in .debug_types > (<=DWARF-4) or the unit header contains DW_UT_type (>=DWARF-5). > DWARFPartialUnit (for DW_TAG_partial_unit) cannot be recognized easily > first. > Besides that one would need then some DWARFRemappedPartialUnit for what I > use > DWARFPartialUnit now. > > I have implemented it according to your advice from this mail - at least > according to how I understood it: > [lldb-dev] RFC for DWZ = DW_TAG_imported_unit + DWARF-5 > supplementary files > https://lists.llvm.org/pipermail/lldb-dev/2017-August/012664.html > > It does not try to share anything at AST level, it only shares DWARF data > (and > thus DWARFCompileUnit). Given that DWZ finds arbitrary unique DWARF > subtrees > I find more logical to decode it at DWARF (and not at AST) level. > > You wrote: > # The drawback is this won't allow sharing /tmp/shared1 or /tmp/shared2 > # between two different top level DWARF files, but it does allow one > # clang::ASTContext to be used between all of them. > > In my implementation /tmp/shared1 > (/usr/lib/debug/.dwz/coreutils-8.27-20.fc27.x86_64) is shared between > multiple > *.so files (which use DW_TAG_imported_unit) at DWARF level, also > clang::ASTContext is shared. > > > # SymbolFileDWARFDebugMap makes it lldb::user_id_t contain the CU index in > the > # top 32 bits, and the DIE offset within that .o file's DWARF in the > bottom 32 > # bits. You could do something similar in your case where the top 32 bits > is > # the index of the DWARF file in the "dwarf[]" array that would be > maintained > # in a new SymbolFileDWARFDWZ subclass. > > DW_TAG_imported_unit+DW_TAG_partial_unit can be also used for optimization > of > a single file (without /usr/lib/debug/.dwz/* file which is used exclusively > for DW_TAG_partial_unit entries). Additionally the tags can be also used > for > recursive
[Lldb-commits] [PATCH] D45332: [LIT] Add new LLDB test format
JDevlieghere abandoned this revision. JDevlieghere added a comment. In https://reviews.llvm.org/D45332#1059429, @labath wrote: > In https://reviews.llvm.org/D45332#1058976, @JDevlieghere wrote: > > > In https://reviews.llvm.org/D45332#1058970, @zturner wrote: > > > > > I don't think `sys.path` is set up correctly to be able to find the > > > lldbtest package from the `lldb/lit` folder. > > > > > > These things kind of evolved separately, and the `lldb/lit` folder was > > > created as a place to start iterating on LLVM-style lit / FileCheck > > > tests. These kind of tests -- by definition -- don't really use the SB > > > API, so no work was ever done to set up paths correctly so that it could > > > write `import lldb` or to re-use any of the other stuff from > > > `packages/Python`. > > > > > > I'm not sure what the best thing to do is, but usually the canonical > > > structuring is to have the test files in the same tree as the lit > > > configuration. So perhaps you could put a lit configuration file in > > > `lldb/packages/Python/lldbsuite` and have that be separate from > > > `lldb/lit`, with the goal of eventually (possibly) merging them. Then > > > have a separate CMake target so you'd still have `check-lldb-lit` which > > > goes into the `lldb/lit` directory, and another one like > > > `check-lldb-lit-dotest` which starts from the > > > `lldb/packages/Python/lldbsuite` directory. > > > > > > On the other hand, if you want to see how `dotest.py` sets up its > > > `sys.path`, have a look at `lldb/test/dotest.py` The magic is in this > > > `use_lldb_suite` function, which walks backwards through the tree until > > > it finds the root, then dives into the `lldbsuite` folder to manually add > > > it to `sys.path`. > > > > > > Do you feel all that outweighs the alternative of just having the format in > > `llvm/Utils` as is the case in this diff? We already have some LLDB > > specific stuff there and I would argue that conceptually it makes (at least > > a little) sense to have all the format living together. > > > I don't think it needs to be that complex. > > You already have LLDB_SOURCE_DIR from `lit.site.cfg.in`, so it should only be > a matter of doing something like this in `lit.cfg`: > > sys.path.append(os.path.join(config.lldb_src_root, > "whereever_is_the_format_file") > from something import LLDBTest > config.test_format = LLDBTest(...) > > > If we can make things as simple as this, then I think we should move this to > the lldb repo. Thanks, that did the trick :-) Repository: rL LLVM https://reviews.llvm.org/D45332 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D45333: WIP: [LIT] Have lit run the lldb test suite
JDevlieghere updated this revision to Diff 141608.
JDevlieghere added a comment.
- Have lldb test format live in lldb repo
https://reviews.llvm.org/D45333
Files:
lit/Suite/lit.cfg
lit/Suite/lit.site.cfg.in
lit/Suite/lldbtest.py
test/CMakeLists.txt
Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt
+++ test/CMakeLists.txt
@@ -152,6 +152,17 @@
add_custom_target(lldb-dotest)
add_dependencies(lldb-dotest ${LLDB_TEST_DEPS})
+configure_file(
+ ${CMAKE_CURRENT_SOURCE_DIR}/../lit/Suite/lit.site.cfg.in
+ ${CMAKE_CURRENT_BINARY_DIR}/../lit/Suite/lit.site.cfg
+ )
+file(GENERATE
+ OUTPUT
+ ${CMAKE_CURRENT_BINARY_DIR}/../lit/Suite/lit.site.cfg
+ INPUT
+ ${CMAKE_CURRENT_BINARY_DIR}/../lit/Suite/lit.site.cfg
+ )
+
# If we're building with an in-tree clang, then list clang as a dependency
# to run tests.
if (TARGET clang)
Index: lit/Suite/lldbtest.py
===
--- /dev/null
+++ lit/Suite/lldbtest.py
@@ -0,0 +1,66 @@
+from __future__ import absolute_import
+import os
+
+import subprocess
+import sys
+
+import lit.Test
+import lit.TestRunner
+import lit.util
+from lit.formats.base import TestFormat
+
+
+class LLDBTest(TestFormat):
+def __init__(self, dotest_cmd):
+self.dotest_cmd = dotest_cmd
+
+def getTestsInDirectory(self, testSuite, path_in_suite, litConfig,
+localConfig):
+source_path = testSuite.getSourcePath(path_in_suite)
+for filename in os.listdir(source_path):
+# Ignore dot files and excluded tests.
+if (filename.startswith('.') or filename in localConfig.excludes):
+continue
+
+# Ignore files that don't start with 'Test'.
+if not filename.startswith('Test'):
+continue
+
+filepath = os.path.join(source_path, filename)
+if not os.path.isdir(filepath):
+base, ext = os.path.splitext(filename)
+if ext in localConfig.suffixes:
+yield lit.Test.Test(testSuite, path_in_suite +
+(filename, ), localConfig)
+
+def execute(self, test, litConfig):
+if litConfig.noExecute:
+return lit.Test.PASS, ''
+
+if test.config.unsupported:
+return (lit.Test.UNSUPPORTED, 'Test is unsupported')
+
+testPath, testFile = os.path.split(test.getSourcePath())
+testName, testExt = os.path.splitext(testFile)
+cmd = self.dotest_cmd + [testPath, '-p', testName]
+print ' '.join(cmd)
+
+try:
+out, err, exitCode = lit.util.executeCommand(
+cmd,
+env=test.config.environment,
+timeout=litConfig.maxIndividualTestTime)
+except lit.util.ExecuteCommandTimeoutException:
+return (lit.Test.TIMEOUT, 'Reached timeout of {} seconds'.format(
+litConfig.maxIndividualTestTime))
+
+if exitCode:
+return lit.Test.FAIL, out + err
+
+passing_test_line = 'RESULT: PASSED'
+if passing_test_line not in out and passing_test_line not in err:
+msg = ('Unable to find %r in dotest output:\n\n%s%s' %
+ (passing_test_line, out, err))
+return lit.Test.UNRESOLVED, msg
+
+return lit.Test.PASS, ''
Index: lit/Suite/lit.site.cfg.in
===
--- /dev/null
+++ lit/Suite/lit.site.cfg.in
@@ -0,0 +1,28 @@
+@LIT_SITE_CFG_IN_HEADER@
+
+config.test_exec_root = "@LLVM_BINARY_DIR@"
+config.llvm_src_root = "@LLVM_SOURCE_DIR@"
+config.llvm_obj_root = "@LLVM_BINARY_DIR@"
+config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
+config.llvm_libs_dir = "@LLVM_LIBS_DIR@"
+config.llvm_build_mode = "@LLVM_BUILD_MODE@"
+config.lit_tools_dir = "@LLVM_LIT_TOOLS_DIR@"
+config.lldb_obj_root = "@LLDB_BINARY_DIR@"
+config.lldb_src_root = "@LLDB_SOURCE_DIR@"
+config.target_triple = "@TARGET_TRIPLE@"
+config.python_executable = "@PYTHON_EXECUTABLE@"
+config.dotest_path = "@LLDB_SOURCE_DIR@/test/dotest.py"
+config.dotest_args_str = "@LLDB_DOTEST_ARGS@"
+
+# Support substitution of the tools and libs dirs with user parameters. This is
+# used when we can't determine the tool dir at configuration time.
+try:
+config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
+config.llvm_libs_dir = config.llvm_libs_dir % lit_config.params
+config.llvm_build_mode = config.llvm_build_mode % lit_config.params
+except KeyError as e:
+key, = e.args
+lit_config.fatal("unable to find %r parameter, use '--param=%s=VALUE'" % (key,key))
+
+# Let the main config do the real work.
+lit_config.load_config(config, "@LLDB_SOURCE_DIR@/lit/Suite/lit.cfg")
Index: lit/Suite/lit.cfg
===
--- /dev/null
+++ lit/Suite/lit.cfg
@@ -0,0 +1,29 @@
+# -*- Pyt
Re: [Lldb-commits] [PATCH] D45170: Cleanup DWARFCompileUnit and DWARFUnit in preparation for adding DWARFTypeUnit
On Mon, 09 Apr 2018 11:52:28 +0200, Pavel Labath wrote: > I'm hoping that I can stay clear of > the ongoing work on dwz&type units, as all of this happens in > SymbolFileDWARF, which you don't seem to touch that much. With excluded mass renaming ( https://reviews.llvm.org/D40467 ) and testcases (https://reviews.llvm.org/D40475 https://reviews.llvm.org/D43512 ) DWZ is not just in SymbolFileDWARF. But I can keep rebasing it. Jan D40468..D40474 include/lldb/Utility/ConstString.h | 12 ++ include/lldb/Utility/FileSpec.h| 8 + source/Plugins/SymbolFile/DWARF/CMakeLists.txt | 2 + .../SymbolFile/DWARF/DWARFASTParserClang.cpp | 19 ++- .../Plugins/SymbolFile/DWARF/DWARFASTParserGo.cpp | 3 +- .../SymbolFile/DWARF/DWARFASTParserJava.cpp| 3 +- .../SymbolFile/DWARF/DWARFASTParserOCaml.cpp | 3 +- .../Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp | 130 +++- source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h | 21 ++- .../Plugins/SymbolFile/DWARF/DWARFCompileUnitDWZ.h | 40 + source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp | 16 +- source/Plugins/SymbolFile/DWARF/DWARFDIE.h | 3 + source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp | 91 +-- source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h | 16 ++ .../SymbolFile/DWARF/DWARFDebugInfoEntry.cpp | 31 +++- .../Plugins/SymbolFile/DWARF/DWARFFileOffset.cpp | 15 ++ source/Plugins/SymbolFile/DWARF/DWARFFileOffset.h | 51 +++ source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp | 53 ++- source/Plugins/SymbolFile/DWARF/DWARFFormValue.h | 3 +- .../Plugins/SymbolFile/DWARF/DWARFPartialUnit.cpp | 16 ++ source/Plugins/SymbolFile/DWARF/DWARFPartialUnit.h | 38 + source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp | 82 +- source/Plugins/SymbolFile/DWARF/DWARFUnit.h| 9 +- .../Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp | 170 - source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h | 47 ++ .../SymbolFile/DWARF/UniqueDWARFASTType.cpp| 1 + 26 files changed, 819 insertions(+), 64 deletions(-) ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D45333: WIP: [LIT] Have lit run the lldb test suite
labath added a comment. In https://reviews.llvm.org/D45333#1058916, @JDevlieghere wrote: > This isn't meant to be checked-in as is, however I'm looking for feedback as > early as possible. > > There are currently two problems with the current diff: > > - `./bin/llvm-lit ../llvm/tools/lldb/lit/Suite/` doesn't work, and I haven't > figured out why yet. > - We'd run the (do)test-suite twice, once as part lit and once as part of > `check-lldb`. I think this is quite close to a working diff. The "running twice" issue can be fixed easily, I presume, and the rest of the issues I see are just minor details. For the llvm-lit issue, I think it would be best if it worked like: llvm-lit .../lldb/packages/Python/lldbsuite/test as then (I hope) I could also specify some folder of that and run only the tests under that subfolder. However, I think we could live without that, initially. Comment at: lit/Suite/lit.cfg:17 +# test_exec_root: The root path where tests should be run. +config.test_source_root = os.path.join(config.lldb_src_root, 'test', 'testcases') +config.test_exec_root = config.test_source_root The testcases symlink thingy will not work on windows. I think you'll have to put the full path here. Comment at: lit/Suite/lldbtest.py:45 +testName, testExt = os.path.splitext(testFile) +cmd = self.dotest_cmd + [testPath, '-p', testName] +print ' '.join(cmd) I think -p should match agains the full file name (i.e., you should be able to just pass `testFile` here). Comment at: lit/Suite/lldbtest.py:46 +cmd = self.dotest_cmd + [testPath, '-p', testName] +print ' '.join(cmd) + It looks like `executeCommand` accepts a list of args for a command as well, so it might be best to keep `cmd` as such. https://reviews.llvm.org/D45333 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D44306: Move Args::StringToAddress to Target::EvaluateAddressExpression
labath added a comment. Jim, judging by the comment in https://reviews.llvm.org/D44306#1037587 you were fine with this patch except the naming part. Now that that's fixed, I hope this should be fine. Unless I hear from you, I am going to commit this so I can continue with re-layering the `Args` class. https://reviews.llvm.org/D44306 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32167: Add support for type units (.debug_types) to LLDB in a way that is compatible with DWARF 5
jankratochvil added inline comments.
Herald added a reviewer: espindola.
Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:595
+ uint64_t debug_info_size = get_debug_info_data().GetByteSize();
+ data_segment.m_data.OffsetData(debug_info_size);
+}
I do not like this `DWARFDataExtractor::m_start` modification, it sort of
corrupts the `DataExtractor` and various operations stop working then - such as
`DWARFDataExtractor::GetByteSize()`. DWZ patch makes from current `dw_offset_t`
a virtual (remapped) offset and introduces new physical file section offset
which is looked up for data extraction. The file offset is represented as
`DWARFFileOffset` in D40474, instead of `bool m_is_dwz;` there could be some
`enum { DEBUG_INFO, DEBUG_TYPES, DWZ_DEBUG_INFO } m_where;` instead.
https://reviews.llvm.org/D32167
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D44306: Move Args::StringToAddress to Target::EvaluateAddressExpression
jingham accepted this revision. jingham added a comment. This revision is now accepted and ready to land. Yes, with your updated naming, I am fine with this. https://reviews.llvm.org/D44306 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32167: Add support for type units (.debug_types) to LLDB in a way that is compatible with DWARF 5
clayborg added a comment.
Is there a link to some documentation that explains what DWZ does? I found a
bunch of blurbs and man pages, but nothing useful. Nothing is found when I look
for "DWZ" in either the DWARF 4 or DWARF 5 spec.
Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:595
+ uint64_t debug_info_size = get_debug_info_data().GetByteSize();
+ data_segment.m_data.OffsetData(debug_info_size);
+}
jankratochvil wrote:
> I do not like this `DWARFDataExtractor::m_start` modification, it sort of
> corrupts the `DataExtractor` and various operations stop working then - such
> as `DWARFDataExtractor::GetByteSize()`. DWZ patch makes from current
> `dw_offset_t` a virtual (remapped) offset and introduces new physical file
> section offset which is looked up for data extraction. The file offset is
> represented as `DWARFFileOffset` in D40474, instead of `bool m_is_dwz;` there
> could be some `enum { DEBUG_INFO, DEBUG_TYPES, DWZ_DEBUG_INFO } m_where;`
> instead.
This means that this diff doesn't affect all of the other DWARF code. Nothing
in .debug_types will refer to anything else (not DW_FORM_ref_addr, or any
external references). So this trick allows us to just treat .debug_info as if
.debug_types was appended to the end since nothing in .debug_types refers to
any DIE outside of its type unit. This also mirrors what will actually happen
with DWARF5 when all of the data is contained inside of the .debug_info
section. This allows each DIE to have a unique "ID". Any other change requires
a lot of changes to the DWARF parser and logic. So I actually like this
feature. We can fix the GetByteSize() if needed. Basically every object in
DWARf right now must be able to make a unique 64 bit unsigned integer ID in
some way that we can get back to that info and partially parse more. These are
handed out as lldb::user_id_t values for types, functions and more. Each flavor
of DWARF will encode what they want into here. The normal DWARF it is just the
absolute offset within the .debug_info. With .debug_types we just add the size
of the .debug_info to the ID. For DWARF in .o files on Darwin, we encode the
compile unit index into the top 32 bits and the DIE offset into the lower, DWO
does something just as DWZ will need to. DWARFFileOffset doesn't mean much if
there are multiple files. We have many competing type uniquing/debug info size
reduction strategies being employed here. I can't believe we have DWO, DWZ, and
debug types... But we have to make them all work. We can't just use the
absolute file offset because DWO used external files where the file offsets
could be the same in the external .o files... Not sure how this works with DWZ
or what the best option is. I will read up on DWZ so I can propose some viable
options. But each new flavor of the day that gets added the DWARF parser is
adding a bunch of logic and edge cases. If two technologies (DWZ + DWO, DWZ +
debug_types, etc) are used together, we need to ensure they can.
https://reviews.llvm.org/D32167
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32167: Add support for type units (.debug_types) to LLDB in a way that is compatible with DWARF 5
clayborg added a comment. Found the DWZ stuff: http://www.dwarfstd.org/ShowIssue.php?issue=120604.1&type=open https://reviews.llvm.org/D32167 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32167: Add support for type units (.debug_types) to LLDB in a way that is compatible with DWARF 5
clayborg added a comment. For DWZ files, it seems types can be contained in external DWARF files and are referred to using new forms. The right way to fix this in LLDB it to load each of these external files as a separate DWZ file (no changes needed to anything) and then teach the SymbolFileDWARF that refers to these files to import the types. If we have 24 shared libraries that use a single DWZ, we shouldn't be loading it more than once and inlining the DWARF, we should be using the AST importer to import the type from that file into the AST for the current DWARF file. We do have done this with -gmodules already, so DWZ shouldn't be that different. Let me know if I am missing anything. https://reviews.llvm.org/D32167 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
