Re: [lldb-dev] Support for Error Strings in remote protocol
On 26 June 2017 at 18:19, Chris Quenelle via lldb-dev wrote: > > My main concern was that *if* strings are added, there's some > clear documentation about the relationship between the string > and the number to explain what's going on. Based on other > emails in this thread it seems like the numbers are so unreliable that > it might not be worth the trouble. > > What about this approach instead? > > Define a new mode of operation called something like "extended error > response" > and invent some way for the client to 1) detect if it's supported in the > server and then > 2) to enable the mode in the server. > > Then define a better error interface. You'd want it to resemble the > existing one > to make it easy for clients to enable it without having to write a bunch of > new code. > > If many things can go wrong in the server, then you might want to have some > arbitrary > lines of text that can be retrieved by the client, and which are defined as > "human readable only" In other words, warn clients not to parse this > extended > "Error log" type of string stuff. The client could dump that to the human > on request. > > That would give a lot of flexibility for the server to spit ad-hoc strings > into the error buffer. I think that pretty much sums up what we were talking about. The client would enable the packet via e.g. QEnableStringErrors packet (the servers already know to reply "unsupported packet" to any packets they don't understand). Then the server can send "Exx;some_error_string" (instead of the usual "Exx"). Later, when the client converts that into a Status object he will use that string to initialize the error string. If the error string is not present he will simply initialize the error string to "Error 47". All of this would be completely invisible to all but the lowest layers of the gdb protocol code. > > You could also define a strict set of numeric codes for things that are > supposed to > common and stable between server versions and implementations. But that > would > still be within the "extended error response" mode. > Right I don't think we have a use case for these extended error codes, so I'd postpone that discussion until a need arises. (Mainly because maintaining a set of backward/forward compatible set of numeric error codes is a pain). ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 33603] lldb unable to demangle lambdas in destructors
https://bugs.llvm.org/show_bug.cgi?id=33603 lab...@google.com changed: What|Removed |Added CC||lab...@google.com Assignee|lldb-dev@lists.llvm.org |lab...@google.com --- Comment #1 from lab...@google.com --- Seems to work for me: (lldb) bt * thread #1, name = 'a.out', stop reason = step in * frame #0: 0x0040068c a.out`Impl::~Impl(__closure=0x7fffdbcf)::'lambda'()::operator()() const at a.cc:13 frame #1: 0x004006ec a.out`void Impl::ImplTemplateFunc(this=0x7fffdbef, f=0x7fffdbcf)::'lambda'()&&) at a.cc:8 frame #2: 0x004006cd a.out`Impl::~Impl(this=0x7fffdbef) at a.cc:14 frame #3: 0x00400677 a.out`main at a.cc:20 frame #4: 0x7772ff45 libc.so.6`__libc_start_main(main=(a.out`main at a.cc:18), argc=1, argv=0x7fffdce8, init=, fini=, rtld_fini=, stack_end=0x7fffdcd8) at libc-start.c:287 frame #5: 0x00400599 a.out`_start + 41 Which version of lldb are you using? Can you try with latest trunk? -- 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] Support for Error Strings in remote protocol
Hello, I would just like to add one more point to this discussion about error strings being human readable or not, I guess the whole purpose of having error strings, is to present them to human users right ? i mean a use case of sending strings, that are not human readable won't be required. So I can work on this point and upload a patch for review. I will add all people in this discussion in the review as well. On Tue, Jun 27, 2017 at 11:27 AM, Pavel Labath wrote: > On 26 June 2017 at 18:19, Chris Quenelle via lldb-dev > wrote: > > > > My main concern was that *if* strings are added, there's some > > clear documentation about the relationship between the string > > and the number to explain what's going on. Based on other > > emails in this thread it seems like the numbers are so unreliable that > > it might not be worth the trouble. > > > > What about this approach instead? > > > > Define a new mode of operation called something like "extended error > > response" > > and invent some way for the client to 1) detect if it's supported in the > > server and then > > 2) to enable the mode in the server. > > > > Then define a better error interface. You'd want it to resemble the > > existing one > > to make it easy for clients to enable it without having to write a bunch > of > > new code. > > > > If many things can go wrong in the server, then you might want to have > some > > arbitrary > > lines of text that can be retrieved by the client, and which are defined > as > > "human readable only" In other words, warn clients not to parse this > > extended > > "Error log" type of string stuff. The client could dump that to the > human > > on request. > > > > That would give a lot of flexibility for the server to spit ad-hoc > strings > > into the error buffer. > > I think that pretty much sums up what we were talking about. The > client would enable the packet via e.g. QEnableStringErrors packet > (the servers already know to reply "unsupported packet" to any packets > they don't understand). Then the server can send > "Exx;some_error_string" (instead of the usual "Exx"). Later, when the > client converts that into a Status object he will use that string to > initialize the error string. If the error string is not present he > will simply initialize the error string to "Error 47". All of this > would be completely invisible to all but the lowest layers of the gdb > protocol code. > > > > > You could also define a strict set of numeric codes for things that are > > supposed to > > common and stable between server versions and implementations. But that > > would > > still be within the "extended error response" mode. > > > > Right I don't think we have a use case for these extended error codes, > so I'd postpone that discussion until a need arises. (Mainly because > maintaining a set of backward/forward compatible set of numeric error > codes is a pain). > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Core file on arm32
Hello, I am running lldb-3.8 on rpi2. When I load coredump file, lldb exited with seg fault. After digging into this issue, I found that loading core file for 32bit arch does not work well. Last commit for 32bit arch corefile is " From 109a39c9709dbc2bd689469f1ba15efee098ee41 Mon Sep 17 00:00:00 2001 From: Dimitar Vlahovski Date: Fri, 29 Jul 2016 13:18:09 + Subject: [PATCH] Add/fix support for i386 elf core files" Here, it seems that arm32 support is still missing in relase 4.0 branch. Is there any plan to support coredump on arm32 ? or am I missing something ? BR, Chunseok Lee ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Current status of simultaneous multiple target debugging in LLDB
Hi, Could someone please help me on the below? Thanks, Ramana On Mon, Jun 12, 2017 at 11:58 AM, Ramana wrote: > Hi, > > I have to implement a debugger for our HW which comprises of CPU+GPU where > the GPU is coded in OpenCL and is accelerated through OpenVX API in C++ > application which runs on CPU. Our requirement is we should be able to > debug the code running on both CPU and GPU simultaneously with in the same > LLDB debug session. > > Looking at the mailing list archive I see that there were discussions > about this feature in LLDB here http://lists.llvm.org/ > pipermail/lldb-dev/2014-August/005074.html. > > What is the present status i.e. what works today and what is to be > improved of simultaneous multiple target debugging support in LLDB? Were > the changes contributed to LLDB mainstream? > > How can I access the material for http://llvm.org/devmtg/2014-10/#bof5 > (Future directions and features for LLDB) > > Appreciate any help/guidance provided on the same. > > Thanks, > Ramana > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
