Re: [lldb-dev] Support for Error Strings in remote protocol
I’m just a new lurker here, so maybe this is obvious… Is the string part of the programmatic interface? Or just a comment? Does the same numeric code always have the same string? If the same numeric code can have different strings, then the string represents a specialization of the error code? If clients depend on the data that’s in the string, then they may not work correctly in modes of operation where the string is not available from the server. If it’s intended to be part of the API then maybe a structured name/value approach might be better? Or maybe it’s just supposed to be a form self-documentation so that inspection of the raw error codes is easier to diagnose? In that case maybe the string is always 1-to-1 with the error code? > On Jun 21, 2017, at 8:31 AM, Ravitheja Addepally via lldb-dev > wrote: > > Hello all, >Currently the remote protocol in LLDB does not allow sending Error > Strings in response to remote packets, it only allows for "ENN" format where > N is a hex integer. In our current ongoing work, we would like to have > support for Sending Error Strings from lldb-server. I would like to invite > any opinions or suggestions in this matter ? > > A very simple proposal would be to just attach an error string maybe as a > Name:Value Pair ? like so -> > > EXX;"Error String" > or > EXX;M"Error String" > > I guess removing EXX would make it incompatible with gdb-server. Also adding > new packets to query errors might not be desired ? > > > Regards, > A Ravi Theja > > > ___ > 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] Support for Error Strings in remote protocol
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. 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. On Mon, Jun 26, 2017 at 7:29 AM, Ravitheja Addepally < ravithejaw...@gmail.com> wrote: > Hello, > From my understanding (please correct me if i am wrong) , currently the > error codes returned by lldb-server are completely arbitrary. > Now the SBError class in the public API interface of lldb does contain a > string. I think in erroneous cases, lldb seems to set the String > in the lldb Status class more often than the error code. I seriously doubt > if there is a coherent structure in the error classes. > > This whole error structure is borrowed from GDB, which is vague about > error codes. Now there are two questions we need to answer -> > 1) Do we want to have ability to send error strings in the error packets ? > 2) If Yes then how ? > > > > On Fri, Jun 23, 2017 at 1:01 AM, Chris Quenelle wrote: > >> I’m just a new lurker here, so maybe this is obvious… >> >> Is the string part of the programmatic interface? Or just a comment? >> Does the same numeric code always have the same string? >> If the same numeric code can have different strings, then the string >> represents a specialization of the error code? If clients depend on >> the data that’s in the string, then they may not work correctly in >> modes of operation where the string is not available from the server. >> >> If it’s intended to be part of the API then maybe a structured name/value >> approach might be better? >> >> Or maybe it’s just supposed to be a form self-documentation so that >> inspection >> of the raw error codes is easier to diagnose? In that case maybe the >> string >> is always 1-to-1 with the error code? >> >> > On Jun 21, 2017, at 8:31 AM, Ravitheja Addepally via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> > >> > Hello all, >> >Currently the remote protocol in LLDB does not allow sending >> Error Strings in response to remote packets, it only allows for "ENN" >> format where N is a hex integer. In our current ongoing work, we would like >> to have support for Sending Error Strings from lldb-server. I would like to >> invite any opinions or suggestions in this matter ? >> > >> > A very simple proposal would be to just attach an error string maybe as >> a Name:Value Pair ? like so -> >> > >> > EXX;"Error String" >> > or >> > EXX;M"Error String" >> > >> > I guess removing EXX would make it incompatible with gdb-server. Also >> adding new packets to query errors might not be desired ? >> > >> > >> > Regards, >> > A Ravi Theja >> > >> > >> > ___ >> > 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] Prologue instructions having line information
Have you guys considered going all the way and recording multiple layers of line information for the same range of instructions, and allowing the user to jump up and down through the not-really-there function calls? That seems like a very usefuil features for looking at optimized code. You’d need an extension to the dwarf information of some kind. Chris > On Sep 14, 2017, at 11:29 AM, Jim Ingham via lldb-dev > wrote: > > This is only tangential, but it is a known bug that when we stop on a line > that starts an inlined block we don't pretend we're in the outer function > first, so the user can "step-in" to the inlined function. This is > particularly notable when you have several nested levels of inlining starting > at the same address, we say the naive thing - that we're in the innermost > function, rather than setting up a set of fake step-in's that mirror the > inline nesting. If somebody wants to take a whack at fixing that it would be > great. Shouldn't be too hard. We need to do other kinds of fakery as well, > for instance if you have three levels of nested inlining and you set a > breakpoint by specifying the middle function, then when you hit that > breakpoint we should pretend we've just stepped into the middle function. > > We handle these fictions with straight-line stepping when it encounters > inlining pretty much okay. But when we're just running to an address (and > apparently when pushing past the prologue) we're not telling the right story. > > Jim > >> On Sep 14, 2017, at 3:20 AM, Tamas Berghammer via lldb-dev >> wrote: >> >> Hi Carlos, >> >> Thank your for looking into the LLDB failure. I looked into it briefly and >> the issue is that we have have 2 function f and g where g is inlined into f >> as the first call and this causes the first non-prologue line entry of f to >> be inside the address range of g what means that when we step info f from >> outside we will end up inside g instead. Previously the first line entry for >> f matched with the start address of the inlined copy of g where LLDB was >> able to handle the stepping properly. >> >> For the concrete example you should compile >> https://github.com/llvm-mirror/lldb/blob/26fea9dbbeb3020791cdbc46fbf3cc9d7685d7fd/packages/Python/lldbsuite/test/functionalities/inline-stepping/calling.cpp >> with "/mnt/ssd/ll/git/build/host-release/bin/clang-5.0 -std=c++11 -g -O0 >> -fno-builtin -m32 --driver-mode=g++ calling.cpp" and then observe that >> caller_trivial_2 have a DW_AT_low_pc = 0x8048790 and the inlined >> inline_trivial_1 inside it have a DW_AT_low_pc = 0x8048793 but the first >> line entry after "Set prologue_end to true" is at 0x8048796 while previously >> it was at 0x8048793. >> >> Tamas >> >> On Thu, Sep 14, 2017 at 9:59 AM Carlos Alberto Enciso via lldb-dev >> wrote: >> Hi, >> >> I have been working on a compiler issue, where instructions associated to >> the function prolog are assigned line information, causing the debugger to >> show incorrectly the beginning of the function body. >> >> For a full description, please see: >> >> https://reviews.llvm.org/D37625 >> https://reviews.llvm.org/rL313047 >> >> The submitted patch caused some LLDB tests to fail. I have attached the log >> failure. >> >> I have no knowledge about the test framework used by LLDB. >> >> What is the best way to proceed in this case? >> >> Thanks very much for your feedback. >> >> Carlos Enciso >> >> >> >> ___ >> 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 ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Prologue instructions having line information
> On Sep 14, 2017, at 3:32 PM, Jim Ingham wrote: > > This is supported (admittedly a little awkwardly) in DWARF with the > DW_TAG_inline_subroutine DIE's in the debug_info section of the DWARF. They > can expresses the nesting fully. > Sorry for the delay in responding. For now, I don’t have anything interesting to say about how lldb keeps track of which logical function it’s in when a single instruction maps to multiple functions. Jim’s comments seem logical. For all the places in lldb that convert an instruction location into a function those would be places to look at the code and think about doing something more fancy. I did have some thoughts on the range list encoding. What follows is not a recommendation, it's just random musings. range lists... They seem to take up more space than they need to. So for a single inline instance you need: (assuming 64 bits obviously) 2x64 base address 2x64 end of list Plus 2x64 for every continuous block of instructions. Assuming the usual case of inlining is mixed with code scheduling and other optimizations, a single inlined instance is likely to be split up pretty thoroughly. (This is all logical guesses, I haven't gathered any statistics.) So if you've got 10 instruction split into 5 chunks then you need (1+5+1) * (64*2) which is 112 bytes. Since most inlined functions are very small the overhead of 4 address words just to open up a range list seems pretty inefficient. You're effectively painting a boolean property on a subset of the instructions in a function. With one property per inlined instance. In the old Sun days we had a desire to do this for a couple of different kinds of information so we invested in a fairly concise way to record it. We just made a sorted list of the instruction offsets from the start of the containing function. Then encoded the sorted list of numbers differentially and stored it as a list of ULEBs in a raw data block attribute attached to a die that describes the property we're describing. It was used for describing ctor and dtor code blocks among other things. So if you have these function offsets of instructions: 1001 1002 1005 1010 1030 You end up with a list of LEBs like: 1001 1 3 5 20(the last 4 numbers are the differences between adjacent pairs) And and since LEBs are fairly short when they are small it doesn't take much space. So for this example I think it would be just 6 bytes. If you had 10 instructions like I used above, then you'd have 10 bytes plus a few extra bytes for the larger offsets. It's much shorter if you can do without address-sized fields, and it's easier on the linker to avoid lots of relocations. But the down side is that using relocations and offsets allows you to generate the section data using assembly syntax without teaching your assembler how to generate special dwarf data. So that may be why dwarf has relied a little too heavily on addresses and relocations for some things. But that's just guess. Now I noticed there was an issue that Paul Robinson mentioned on the intertubes where lldb prefers fixed-size dies. The solution in the Studio compilers puts the data block inside the die, but it works just as well to factor the data out into a different section the same way range lists work. It's a little less space efficient because of the address pointing at the external section, but still better than range lists. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Prologue instructions having line information
> On Sep 22, 2017, at 4:18 PM, Robinson, Paul wrote: > > For contiguous ranges described by low_pc/hi_pc attribute > pairs, the hi_pc can be a constant for the length, so you save > a little space and a relocation. I think that’s in DWARF 4. > > DWARF 5 redid the ranges section, to do a lot more with ULEBs > and offsets from base addresses. So it should be a lot more > compact. That requires producers to speak DWARF 5, of course; > I'm trying to make time to do that for Clang. Good to know, I’ll check that out.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
