aleksandr.urakov added a comment.
I've tried to parse with it a name like
N0::`unnamed namespase'::Name
and it can't parse it correctly. May be it just can't parse MSVC demangled
names?
Unfortunately, I can't look at the tests right now, I have a vacation. I'll
look at these a week later, o
asmith updated this revision to Diff 167670.
https://reviews.llvm.org/D52627
Files:
source/Symbol/Symtab.cpp
Index: source/Symbol/Symtab.cpp
===
--- source/Symbol/Symtab.cpp
+++ source/Symbol/Symtab.cpp
@@ -139,6 +139,8 @@
clayborg added a comment.
If this isn't fixing up cases where the global does have an address (not just
set to zero), we need to fix the code so it relinks the global address
correctly.
https://reviews.llvm.org/D52678
___
lldb-commits mailing list
clayborg added a comment.
See SymbolFileDWARF::ParseVariableDIE. It has code that links up the DW_OP_addr:
if (is_static_lifetime) {
if (is_external)
scope = eValueTypeVariableGlobal;
else
scope = eValueTypeVariableStatic;
if (debug_map_symfile) {
// When leavin
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
Any idea why the module isn't set correctly in certain dwarf expressions? Any
variable that is created from debug info that pertains to a module should have
its DWARFExpression c
labath added a comment.
In https://reviews.llvm.org/D52461#1249259, @aleksandr.urakov wrote:
> It seems that `CPlusPlusLanguage::MethodName` is backed by LLDB
> `CPlusPlusNameParser`, which can't parse demangled names...
What makes you say that? If you look at the MethodName unit tests
(`unit
labath added inline comments.
Herald added a subscriber: arphaman.
Comment at: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp:179
+ if (!m_die_array.empty()) {
+lldbassert(!m_first_die || m_first_die == m_die_array.front());
+m_first_die = m_die_array.front();
aleksandr.urakov added a comment.
Ok, I'll look at this, thank you!
Repository:
rLLDB LLDB
https://reviews.llvm.org/D52461
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
krytarowski added a comment.
In https://reviews.llvm.org/D52532#1250404, @labath wrote:
> In https://reviews.llvm.org/D52532#1246173, @krytarowski wrote:
>
> > I was wondering whether we want to normalize this inside the kernel and
> > always advance the Program Counter.. but it's easier to mana
Author: labath
Date: Sun Sep 30 09:12:09 2018
New Revision: 343411
URL: http://llvm.org/viewvc/llvm-project?rev=343411&view=rev
Log:
Fix NetBSD build for r343409
Forgot to remove the method declaration from the header.
Modified:
lldb/trunk/source/Plugins/Process/NetBSD/NativeProcessNetBSD.h
This revision was automatically updated to reflect the committed changes.
Closed by commit rL343409: Pull GetSoftwareBreakpointPCOffset into base class
(authored by labath, committed by ).
Herald added a subscriber: llvm-commits.
Repository:
rL LLVM
https://reviews.llvm.org/D52532
Files:
ll
Author: labath
Date: Sun Sep 30 08:58:52 2018
New Revision: 343409
URL: http://llvm.org/viewvc/llvm-project?rev=343409&view=rev
Log:
Pull GetSoftwareBreakpointPCOffset into base class
Summary:
This function encodes the knowledge of whether the PC points to the
breakpoint instruction of the one fo
labath added a comment.
In https://reviews.llvm.org/D52532#1246173, @krytarowski wrote:
> I was wondering whether we want to normalize this inside the kernel and
> always advance the Program Counter.. but it's easier to manage it in userland.
I am generally in favour of keeping the kernel simp
Hui added a comment.
In https://reviews.llvm.org/D52461#1249259, @aleksandr.urakov wrote:
> In https://reviews.llvm.org/D52461#1245058, @clayborg wrote:
>
> > Try to use and extend CPlusPlusLanguage::MethodName as needed. I believe it
> > was recently backed by a new clang parser that knows how
14 matches
Mail list logo