[lldb-dev] [Bug 36534] New: SIGSEGV on 'image dump symfile'
https://bugs.llvm.org/show_bug.cgi?id=36534
Bug ID: 36534
Summary: SIGSEGV on 'image dump symfile'
Product: lldb
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: danti...@nvidia.com
CC: llvm-b...@lists.llvm.org
Configured on X86/Linux with:
cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_FLAGS_DEBUG='-O0 -g'
-DCMAKE_CXX_FLAGS_DEBUG='-O0 -g'
-DCMAKE_INSTALL_PREFIX=/home/dantipov/.local/llvm-6.0.0
-DLLVM_TARGETS_TO_BUILD="ARM;AArch64;X86"
LLDB is unable to 'image dump symfile' of itself:
$ pidof lldb
6177
$ /home/dantipov/.local/llvm-6.0.0/bin/lldb
(lldb) version
lldb version 6.0.0 (http://llvm.org/svn/llvm-project/lldb/tags/RELEASE_600/rc3
revision 326179)
clang revision 326179
llvm revision 326179
(lldb) attach 6177
Process 6177 stopped
* thread #1, name = 'lldb', stop reason = signal SIGSTOP
frame #0: 0x7f5518b6b313 libc.so.6`__GI___select(nfds=4,
readfds=0x7ffda6c07ec0, writefds=0x,
exceptfds=0x, timeout=0x) at select.c:41
38 struct timeval *timeout)
39 {
40 #ifdef __NR_select
-> 41 return SYSCALL_CANCEL (select, nfds, readfds, writefds, exceptfds,
42timeout);
43 #else
44 int result;
thread #2, name = 'lldb', stop reason = signal SIGSTOP
frame #0: 0x7f5521fa5cbb libpthread.so.0`__pthread_cond_wait at
futex-internal.h:88
85 {
86 int oldtype;
87 oldtype = __pthread_enable_asynccancel ();
-> 88 int err = lll_futex_timed_wait (futex_word, expected, NULL, private);
89 __pthread_disable_asynccancel (oldtype);
90 switch (err)
91 {
Executable module set to "/home/dantipov/.local/llvm-6.0.0/bin/lldb".
Architecture set to: x86_64--linux.
(lldb) image dump symfile
Stack dump:
0. HandleCommand(command = "image dump symfile")
Segmentation fault (core dumped)
$ gdb -q /home/dantipov/.local/llvm-6.0.0/bin/lldb core.6182
Reading symbols from /home/dantipov/.local/llvm-6.0.0/bin/lldb...done.
[New LWP 6182]
[New LWP 6189]
[New LWP 6183]
[New LWP 6188]
[New LWP 6187]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/home/dantipov/.local/llvm-6.0.0/bin/lldb'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x7fdf4b3f19f0 in lldb_private::UserID::GetID (this=0x10) at
/home/dantipov/llvm/6.0.0/source/tools/lldb/include/lldb/Utility/UserID.h:60
60lldb::user_id_t GetID() const { return m_uid; }
[Current thread is 1 (Thread 0x7fdf532c0580 (LWP 6182))]
(gdb) bt
#0 0x7fdf4b3f19f0 in lldb_private::UserID::GetID (this=0x10) at
/home/dantipov/llvm/6.0.0/source/tools/lldb/include/lldb/Utility/UserID.h:60
#1 0x7fdf4b984cc8 in lldb_private::operator<< (strm=..., uid=...) at
/home/dantipov/llvm/6.0.0/source/tools/lldb/source/Utility/UserID.cpp:19
#2 0x7fdf4b83cd57 in lldb_private::Type::Dump (this=0x0, s=0x7ffe85641720,
show_context=false) at
/home/dantipov/llvm/6.0.0/source/tools/lldb/source/Symbol/Type.cpp:217
#3 0x7fdf4b842e6e in lldb_private::TypeList::Dump (this=0x7fde472b8598,
s=0x7ffe85641720, show_context=false)
at
/home/dantipov/llvm/6.0.0/source/tools/lldb/source/Symbol/TypeList.cpp:105
#4 0x7fdf4b824f62 in lldb_private::SymbolVendor::Dump
(this=0x7fde472b8580, s=0x7ffe85641720)
at
/home/dantipov/llvm/6.0.0/source/tools/lldb/source/Symbol/SymbolVendor.cpp:396
#5 0x7fdf4caec6cd in DumpModuleSymbolVendor (strm=...,
module=0x7fde4460be70) at
/home/dantipov/llvm/6.0.0/source/tools/lldb/source/Commands/CommandObjectTarget.cpp:1431
#6 0x7fdf4caf459a in CommandObjectTargetModulesDumpSymfile::DoExecute
(this=0x17de9e0, command=..., result=...)
at
/home/dantipov/llvm/6.0.0/source/tools/lldb/source/Commands/CommandObjectTarget.cpp:2234
#7 0x7fdf4b7582a2 in lldb_private::CommandObjectParsed::Execute
(this=0x17de9e0, args_string=0x7ffe85641350 "", result=...)
at
/home/dantipov/llvm/6.0.0/source/tools/lldb/source/Interpreter/CommandObject.cpp:991
#8 0x7fdf4b745c65 in lldb_private::CommandInterpreter::HandleCommand
(this=0x17b6cc0, command_line=0x1908ae0 "image dump symfile",
lazy_add_to_history=lldb_private::eLazyBoolCalculate, result=...,
override_context=0x0, repeat_on_empty_command=true, no_context_switching=false)
at
/home/dantipov/llvm/6.0.0/source/tools/lldb/source/Interpreter/CommandInterpreter.cpp:1683
#9 0x7fdf4b74a8b3 in
lldb_private::CommandInterpreter::IOHandlerInputComplete (this=0x17b6cc0,
io_handler=..., line="image dump symfile")
at
/home/dantipov/llvm/6.0.0/source/tools/lldb/source/Interpreter/CommandInterpreter.cpp:2771
#10 0x7fdf4b610c8b in lldb_private::IOHandlerEditline::Run (this=0x18c0bf0)
at /home/da
[lldb-dev] [Bug 36538] New: Odd 'watchpoint set' errors on Android target
https://bugs.llvm.org/show_bug.cgi?id=36538 Bug ID: 36538 Summary: Odd 'watchpoint set' errors on Android target Product: lldb Version: 6.0 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: danti...@nvidia.com CC: llvm-b...@lists.llvm.org Created attachment 19967 --> https://bugs.llvm.org/attachment.cgi?id=19967&action=edit Sample program $ /home/dantipov/.local/llvm-6.0.0/bin/lldb (lldb) platform select remote-android Platform: remote-android Connected: no (lldb) platform connect connect://localhost: Platform: remote-android Triple: aarch64-*-linux-android OS Version: 24.0.0 (3.10.96+) Kernel: #1 SMP PREEMPT Mon Feb 13 20:11:02 PST 2017 Hostname: localhost Connected: yes WorkingDir: / (lldb) attach 14797 Process 14797 stopped * thread #1, name = 't-watchpoint', stop reason = signal SIGSTOP frame #0: 0x002000f3cc44 libc.so`nanosleep + 4 libc.so`nanosleep: -> 0x2000f3cc44 <+4>: svc#0 0x2000f3cc48 <+8>: cmnx0, #0x1, lsl #12 ; =0x1000 0x2000f3cc4c <+12>: cneg x0, x0, hi 0x2000f3cc50 <+16>: b.hi 0x2000ef644c ; __set_errno_internal Executable module set to "/home/dantipov/.lldb/module_cache/remote-android/.cache/CFD513B9----/t-watchpoint". Architecture set to: aarch64--linux-android. (lldb) watchpoint list Number of supported hardware watchpoints: 4 No watchpoints currently set. (lldb) watchpoint set variable A Watchpoint created: Watchpoint 1: addr = 0x2000da3e60 size = 4 state = enabled type = w watchpoint spec = 'A' new value: 7 (lldb) watchpoint set variable B error: Watchpoint creation failed (addr=0x2000da3e64, size=4, variable expression='B'). error: sending gdb watchpoint packet failed (lldb) watchpoint set variable C Watchpoint created: Watchpoint 3: addr = 0x2000da3e68 size = 4 state = enabled type = w watchpoint spec = 'C' new value: 7 (lldb) watchpoint set variable D error: Watchpoint creation failed (addr=0x2000da3e6c, size=4, variable expression='D'). error: sending gdb watchpoint packet failed (lldb) watchpoint set variable E Watchpoint created: Watchpoint 5: addr = 0x2000da3e70 size = 4 state = enabled type = w watchpoint spec = 'E' new value: 6 (lldb) watchpoint list Number of supported hardware watchpoints: 4 Current watchpoints: Watchpoint 1: addr = 0x2000da3e60 size = 4 state = enabled type = w watchpoint spec = 'A' new value: 7 Watchpoint 3: addr = 0x2000da3e68 size = 4 state = enabled type = w watchpoint spec = 'C' new value: 7 Watchpoint 5: addr = 0x2000da3e70 size = 4 state = enabled type = w watchpoint spec = 'E' new value: 6 Probably I need an advice to provide more information (extra logging?). -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [6.0.0 Release] Release Candidate 3 tagged
On Fri, Feb 23, 2018 at 4:14 PM, Hans Wennborg wrote: > Dear testers, > > 6.0.0-rc3 was just tagged, after r325901 on the branch. > > There are still a few open blockers, but I'm not sure we'll actually > end up blocking on all of them. So depending on what comes up, this > release candidate is probably pretty close to what the final release > will look like (I'm still hoping for more release notes, though). > > I'm hoping we can get to 'final' sometime next week. > > Please test, let me know how it goes, and upload binaries. So far nothing new has come up, so the plan is to tag 'final' tomorrow (Wednesday) morning European time. If there are any problems you think I should know about, now is the time to let me know :-) ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 36540] New: "error: this file does not represent a loadable dylib" when loading libsosplugin.so plugin from Python
https://bugs.llvm.org/show_bug.cgi?id=36540
Bug ID: 36540
Summary: "error: this file does not represent a loadable dylib"
when loading libsosplugin.so plugin from Python
Product: lldb
Version: 4.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: evg...@loop54.com
CC: llvm-b...@lists.llvm.org
I'm trying to run the following Python script on Ubuntu 16.04.4 x64:
import lldb
import sys
pid = int(sys.argv[1])
print("Attaching to process %d using %s" % (pid,
lldb.SBDebugger.GetVersionString()))
debugger = lldb.SBDebugger.Create()
target = debugger.CreateTarget('')
error = lldb.SBError()
process = target.AttachToProcessWithID(debugger.GetListener(), pid, error)
if not error.Success():
raise Exception("Failed to attach")
sos_path = "/opt/dotnet/shared/Microsoft.NETCore.App/2.0.5/libsosplugin.so"
debugger.HandleCommand("plugin load %s" % sos_path)
It gives an error:
$ python loadsostest.py 2036
Attaching to process 2036 using lldb version 4.0.0
error: this file does not represent a loadable dylib
However, I can load the same plugin successfully from the command line:
lldb-4.0 -o "plugin load
/opt/dotnet/shared/Microsoft.NETCore.App/2.0.5/libsosplugin.so" -p 2036
(lldb) process attach --pid 2036
Process 2036 stopped
...
Executable module set to "/opt/dotnet/dotnet".
Architecture set to: x86_64-pc-linux.
(lldb) plugin load
/opt/dotnet/shared/Microsoft.NETCore.App/2.0.5/libsosplugin.so
LLDB version: 'lldb version 4.0.0'(lldb)
--
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [6.0.0 Release] Release Candidate 3 tagged
W dniu pią, 23.02.2018 o godzinie 16∶14 +0100, użytkownik Hans Wennborg via Release-testers napisał: > Dear testers, > > 6.0.0-rc3 was just tagged, after r325901 on the branch. > > There are still a few open blockers, but I'm not sure we'll actually > end up blocking on all of them. So depending on what comes up, this > release candidate is probably pretty close to what the final release > will look like (I'm still hoping for more release notes, though). > > I'm hoping we can get to 'final' sometime next week. > > Please test, let me know how it goes, and upload binaries. > All looks good-ish on Gentoo end. No new issues and no blockers. -- Best regards, Michał Górny ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] FreeBSD LLDB buildbot
On 26 February 2018 at 22:32, Ed Maste wrote: > > 2. Install required packages: > # pkg install cmake ninja swig30 subversion py27-pip Also gmake and bash. > The host is running a FreeBSD 12-CURRENT kernel and to enable tests I > expect I'll create a new FreeBSD 12 builder, which can be initially > connected to the staging master. I've sent connection details for lldb-amd64-ninja-freebsd-wip-12, and will post a patch for slaves.py and builders.py soon. There is one problem reported by the lit tests with my jail approach: [ RUN ] SocketTest.TCPGetAddress /usr/home/buildbot/scratch/scratch/llvm/tools/lldb/unittests/Host/SocketTest.cpp:207: Failure Expected: "127.0.0.1" To be equal to: socket_a_up->GetRemoteIPAddress().c_str() Which is: "192.168.11.4" In a (default configuration) jail FreeBSD maps 127.0.0.1 to the jail's IP address. Support for independent virtualized network stacks is a more recent addition to FreeBSD and it looks like I'll need to set that up here (or use full virtual machines). ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] FreeBSD LLDB buildbot
On 26 February 2018 at 19:32, Ed Maste via lldb-dev wrote: > 5. I copied the scripts (updateScripts.sh, checkoutSource.sh, etc.) > from the previous buildbot installation (into scratch/scripts/). I > think we should host all scripts for the builders in either the lldb > or zorg repo - is there a reason they're not? The existence of these scripts is a fairly non-standard feature in the llvm buildbot world. They were created to provide a layer of indirection between the buildmaster and the slave. The main reason for that was that there's a fairly elaborate dance you need to do to setup remote testing. Implementing this as a series of buildbot steps was tricky and required a master restart everytime you needed to change things. I wasn't involved in setting this up back then, but I guess at some point someone just got fed up with that and implemented this. I'm don't think we should be recommending using these for new buildbots. There is a more standard lldb buildslave factory class in the zorg repo that does not need these scripts (but probably needs some resuscitation) and that's what I would recommend for the regular setup. The scripted factory can stay for the more advanced uses, but here I would say it's up to the buildslave maintainer to create these scripts for himself. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] how do i submit my patch for 'Support demangling for D symbols via dlopen'
I only briefly scanned the patch, but I'm not sure treating D as another mangling variant of C++ is the best model - I think it will be easier if we gather all the separate language features up in the individual languages. You might have a look at the swift-enabled lldb (https://github.com/apple/swift-lldb/) to see how it is handled there. That's a little weak because we iterate over supported languages by hand. When there were a few that wasn't an issue, but as we pick up more languages, we should introduce a "do over supported languages" feature which would clean up the logic there. Jim > On Feb 26, 2018, at 9:01 PM, Timothee Cour via lldb-dev > wrote: > > https://github.com/llvm-mirror/lldb/pull/3 > > it would be *really* nice if llvm or lldb accepted industry standard > github PR's, at least as an option. Would make contributing so much > easier for outsiders > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Issue: print std unique pointer
Hi,
LLDB is printing a empty value for unique pointers in PowerPC.
And I am investigating a solution for this problem.
The problem occurs because the ptr_obj variable has a empty value in
Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp:73.
I could solve it, changing this line
Plugins/Language/CPlusPlus/LibStdcppTuple.cpp:68
from:
if (name_str.startswith("std::_Tuple_impl<")) {
to:
if (name_str.startswith("std::_Tuple_impl<") ||
name_str.startswith("_M_t") ) {
After this change, the test TestDataFormatterStdUniquePtr pass with success.
And the unique pointers are displayed correctly.
Is there a better solution for that?
Thanks.
Alexandre.
--
Alexandre Yukio Yamashita (DSB)
Instituto de Pesquisas Eldorado
www.eldorado.org.br
+55 19 3757 3201 / +55 19 9 8336 5553
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [6.0.0 Release] Release Candidate 3 tagged
Hi, No major issues seen so far for mips. Binaries uploaded. SHA256(clang+llvm-6.0.0-rc3-mipsel-linux-gnu.tar.xz)= 6e4fab79cc341a9084dab94cced108daff39fcde14a11e8d7ae454e9f92cb77c SHA256(clang+llvm-6.0.0-rc3-mips-linux-gnu.tar.xz)= 54887a039d3d7ccff17a0c7245f4c9d778a1c22f96b619db554849da55293d61 SHA256(clang+llvm-6.0.0-rc3-x86_64-linux-gnu-debian8.tar.xz)= 75f1a18f23b9d34e3f1ebc223ca0071458b9e8b1392040f9b3d1725566ff6ec1 Thanks, Simon From: Release-testers [release-testers-boun...@lists.llvm.org] on behalf of Hans Wennborg via Release-testers [release-test...@lists.llvm.org] Sent: Friday, February 23, 2018 3:14 PM To: Release-testers Cc: llvm-dev; cfe-dev; openmp-dev (openmp-...@lists.llvm.org); LLDB Dev Subject: [Release-testers] [6.0.0 Release] Release Candidate 3 tagged Dear testers, 6.0.0-rc3 was just tagged, after r325901 on the branch. There are still a few open blockers, but I'm not sure we'll actually end up blocking on all of them. So depending on what comes up, this release candidate is probably pretty close to what the final release will look like (I'm still hoping for more release notes, though). I'm hoping we can get to 'final' sometime next week. Please test, let me know how it goes, and upload binaries. Thanks, Hans ___ Release-testers mailing list release-test...@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Issue: print std unique pointer
It depends on the version of the C++ standard library you are using. Is this
the only thing that isn't working in the STL data formatters? I would expect
the STL library to be the same on PowerPC as it is on other platforms so I
wouldn't guess this would be an issue that is arch dependent.
Greg Clayton
> On Feb 27, 2018, at 12:26 PM, Alexandre Yukio Yamashita via lldb-dev
> wrote:
>
> Hi,
>
> LLDB is printing a empty value for unique pointers in PowerPC.
> And I am investigating a solution for this problem.
>
> The problem occurs because the ptr_obj variable has a empty value in
> Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp:73.
>
> I could solve it, changing this line
> Plugins/Language/CPlusPlus/LibStdcppTuple.cpp:68
> from:
> if (name_str.startswith("std::_Tuple_impl<")) {
> to:
> if (name_str.startswith("std::_Tuple_impl<") ||
> name_str.startswith("_M_t") ) {
>
> After this change, the test TestDataFormatterStdUniquePtr pass with success.
> And the unique pointers are displayed correctly.
>
> Is there a better solution for that?
>
> Thanks.
> Alexandre.
>
>
> --
> Alexandre Yukio Yamashita (DSB)
> Instituto de Pesquisas Eldorado
> www.eldorado.org.br
> +55 19 3757 3201 / +55 19 9 8336 5553
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Issue: print std unique pointer
This probably isn't arch-dependent. More likely you just have a
different version of libstdc++. Can you share how the std::unique_ptr
layout looks like for you. This is how my std::unique_ptr looks like
(from libstdc++.so.6.0.22):
(lldb) fr var X -R -T
(std::unique_ptr >) X = {
(std::unique_ptr >::__tuple_type) _M_t = {
(std::_Tuple_impl<0, int *, std::default_delete >)
std::_Tuple_impl<0, int *, std::default_delete > = {
(std::_Head_base<0, int *, false>) std::_Head_base<0, int *, false> = {
(int *) _M_head_impl = 0x55768c20
}
}
}
}
On 27 February 2018 at 12:26, Alexandre Yukio Yamashita via lldb-dev
wrote:
> Hi,
>
> LLDB is printing a empty value for unique pointers in PowerPC.
> And I am investigating a solution for this problem.
>
> The problem occurs because the ptr_obj variable has a empty value in
> Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp:73.
>
> I could solve it, changing this line
> Plugins/Language/CPlusPlus/LibStdcppTuple.cpp:68
> from:
> if (name_str.startswith("std::_Tuple_impl<")) {
> to:
> if (name_str.startswith("std::_Tuple_impl<") ||
> name_str.startswith("_M_t") ) {
>
> After this change, the test TestDataFormatterStdUniquePtr pass with success.
> And the unique pointers are displayed correctly.
>
> Is there a better solution for that?
>
> Thanks.
> Alexandre.
>
>
> --
> Alexandre Yukio Yamashita (DSB)
> Instituto de Pesquisas Eldorado
> www.eldorado.org.br
> +55 19 3757 3201 / +55 19 9 8336 5553
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Issue: print std unique pointer
Then the question becomes how can we identify the STL that is being used
correctly so we can do the right thing. I worry that if std::unique_ptr isn't
working that many many other STL things won't work as well. We are tuned for a
specific STL
> On Feb 27, 2018, at 2:12 PM, Pavel Labath via lldb-dev
> wrote:
>
> This probably isn't arch-dependent. More likely you just have a
> different version of libstdc++. Can you share how the std::unique_ptr
> layout looks like for you. This is how my std::unique_ptr looks like
> (from libstdc++.so.6.0.22):
>
> (lldb) fr var X -R -T
> (std::unique_ptr >) X = {
> (std::unique_ptr >::__tuple_type) _M_t = {
>(std::_Tuple_impl<0, int *, std::default_delete >)
> std::_Tuple_impl<0, int *, std::default_delete > = {
> (std::_Head_base<0, int *, false>) std::_Head_base<0, int *, false> = {
>(int *) _M_head_impl = 0x55768c20
> }
>}
> }
> }
>
> On 27 February 2018 at 12:26, Alexandre Yukio Yamashita via lldb-dev
> wrote:
>> Hi,
>>
>> LLDB is printing a empty value for unique pointers in PowerPC.
>> And I am investigating a solution for this problem.
>>
>> The problem occurs because the ptr_obj variable has a empty value in
>> Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp:73.
>>
>> I could solve it, changing this line
>> Plugins/Language/CPlusPlus/LibStdcppTuple.cpp:68
>> from:
>> if (name_str.startswith("std::_Tuple_impl<")) {
>> to:
>> if (name_str.startswith("std::_Tuple_impl<") ||
>> name_str.startswith("_M_t") ) {
>>
>> After this change, the test TestDataFormatterStdUniquePtr pass with success.
>> And the unique pointers are displayed correctly.
>>
>> Is there a better solution for that?
>>
>> Thanks.
>> Alexandre.
>>
>>
>> --
>> Alexandre Yukio Yamashita (DSB)
>> Instituto de Pesquisas Eldorado
>> www.eldorado.org.br
>> +55 19 3757 3201 / +55 19 9 8336 5553
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
