diff options
| author | Alexander Shaposhnikov <shal1t712@gmail.com> | 2017-09-12 22:14:36 +0000 |
|---|---|---|
| committer | Alexander Shaposhnikov <shal1t712@gmail.com> | 2017-09-12 22:14:36 +0000 |
| commit | ff7b03fc854b7b0fd9f8ea2f1ceee9299dd6628e (patch) | |
| tree | a3dcfcd60270625bbd3d3dd23479867d15b4d60b /libcxx | |
| parent | 760ad5ce0354cd56a465361bf5ef83791d72e629 (diff) | |
| download | bcm5719-llvm-ff7b03fc854b7b0fd9f8ea2f1ceee9299dd6628e.tar.gz bcm5719-llvm-ff7b03fc854b7b0fd9f8ea2f1ceee9299dd6628e.zip | |
[lldb] Adjust UpdateExternalModuleListIfNeeded method for the case of *.dwo
When LLDB loads "external" modules it looks at the
presence of DW_AT_GNU_dwo_name.
However, when the already created module
(corresponding to .dwo itself) is being processed,
it will see the presence of DW_AT_GNU_dwo_name
(which contains the name of dwo file) and
will try to call ModuleList::GetSharedModule again.
In some cases (i.e. for empty files) Clang 4.0
generates a *.dwo file which has DW_AT_GNU_dwo_name,
but no DW_AT_comp_dir. In this case the method
ModuleList::GetSharedModule will fail and
the warning will be printed. To workaround this issue,
one can notice that in this case we don't actually need
to try to load the already loaded module (corresponding to .dwo).
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D37295
llvm-svn: 313083
Diffstat (limited to 'libcxx')
0 files changed, 0 insertions, 0 deletions
