> On Apr 1, 2016, at 3:43 AM, Tamas Berghammer wrote:
>
> tberghammer added a comment.
>
> This assert is NOT verifying the debug info itself. It is verifying that LLDB
> asked the right SymbolFileDWARFDwo to find a DIE based on a DIERef.
> Independently of the debug info (what can be garbage
tberghammer added a comment.
This assert is NOT verifying the debug info itself. It is verifying that LLDB
asked the right SymbolFileDWARFDwo to find a DIE based on a DIERef.
Independently of the debug info (what can be garbage) passed in to LLDB this
assert should never fire if LLDB has no maj
> On Mar 31, 2016, at 11:51 AM, Tamas Berghammer wrote:
>
> This assert isn't checking for the correctness of the debug info (what is a
> program input). It is checking that we passed the DIERef to the correct
> SymbolFileDWARFDwo instance what is the contract of the API and should be
> check
It's a double edged sword though. If you disable them, then sure you don't
crash anymore, but now you don't know when issues actually do happen
because, well, they're disabled. That's why I actually like lldbassert.
You get all the benefits of the assertion such as knowing when bugs happen,
but w
This assert isn't checking for the correctness of the debug info (what is a
program input). It is checking that we passed the DIERef to the correct
SymbolFileDWARFDwo instance what is the contract of the API and should be
checked by an assert. This assert will only fire if we have a bug in LLDB
reg
Moving lldb out of process is a worthy effort, but it is only a partial
solution. We do a lot of things on the users behalf, and if one of these
crashes without really giving the user insight into how to avoid the crash,
while it's great that we didn't also lose some editing changes they had in
> On Mar 31, 2016, at 11:15 AM, Zachary Turner via lldb-commits
> wrote:
>
> I think it depends on how bad the thing that happens is. If you are out of
> memory, sure you can assert. If a syscall fails that is supposed to never
> fail, you can assert.
Admittedly, if you’re out of memory t
I think it depends on how bad the thing that happens is. If you are out of
memory, sure you can assert. If a syscall fails that is supposed to never
fail, you can assert. But if one piece of debug info appears corrupt, I
don't think it's worth bringing down the whole process, which could be an
e
jingham added a subscriber: jingham.
jingham added a comment.
I don't agree that asserts are good in released code unless you have no way of
backing out of the situation you find yourself in. After all, you are saying
to some unlucky user out there that they can't use the debugger on their app
I don't agree that asserts are good in released code unless you have no way of
backing out of the situation you find yourself in. After all, you are saying
to some unlucky user out there that they can't use the debugger on their app
and in general there's nothing they can do about it. Greg's s
clayborg added a comment.
I don't mind asserts when they shouldn't happen if they are lldbassert calls
since these are removed for release builds, but we can't just call assert and
crash because something bad happened. LLDB is a shared library and a framework
and it shouldn't crash no matter wh
tberghammer added inline comments.
Comment at:
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp:136
@@ +135,3 @@
+{
+assert(m_base_dwarf_cu->GetOffset() == die_ref.cu_offset);
+return DebugInfo()->GetDIEForDIEOffset(die_ref.die_offset);
c
clayborg added a comment.
See inlined comment for a follow up fix.
Comment at:
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp:136
@@ +135,3 @@
+{
+assert(m_base_dwarf_cu->GetOffset() == die_ref.cu_offset);
+return DebugInfo()->GetDIEForDIEOffset(die_r
This revision was automatically updated to reflect the committed changes.
Closed by commit rL265011: Fix DWO breakage in r264909 (authored by labath).
Changed prior to commit:
http://reviews.llvm.org/D18646?vs=52196&id=52198#toc
Repository:
rL LLVM
http://reviews.llvm.org/D18646
Files:
ll
tberghammer accepted this revision.
tberghammer added a comment.
This revision is now accepted and ready to land.
Looks good
http://reviews.llvm.org/D18646
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailm
labath created this revision.
labath added reviewers: tberghammer, clayborg.
labath added a subscriber: lldb-commits.
In case of Dwo, DIERef stores a compile unit offset in the main object file,
and not in the dwo.
The implementation of SymbolFileDWARFDwo::GetDIE inherited from SymbolFileDWARF
t
16 matches
Mail list logo
