Re: [lldb-dev] Rust language support question
To these very insightful emails from Greg and Jim, I'd just like to add one request. Please consider the testing strategy of the code you write early on. One of the problems that we have with these language plugins (and why we now have a separate thread considering removal of some of them) is that after the plugin has landed and some time has elapsed with no activity on it, we have no idea if it is even still functional without any tests. While you obviously cannot write an end-to-end test without a rust compiler and runtime libraries around, plenty of code that you will need to write could be unit-tested without any dependencies. E.g. if you go down parse "rust dwarf into clang's astcontext" then the parsing can be tested by feeding it some dwarf (maybe via llvm/DWARFYAML) and dumping out the resulting AST. On 27 January 2018 at 02:51, Jim Ingham via lldb-dev wrote: > Jason points out this was gdb writing out a binary form of gdb's psymtabs to > be a cheap accelerator table. Anyway, having the data representation of > debug information depend on the internal state of either the compiler or > debugger is a fragile thing... > > Jim > > >> On Jan 26, 2018, at 6:16 PM, Jim Ingham wrote: >> >> Note, I think the jury's still out on whether it was a great idea to have >> the swift type representation be the swift compiler's internal state. It >> has proven more than a little fragile. I'm not sure I would suggest that >> route. I vaguely remember back in the day there was a -g flag in gcc that >> produced a compiler state dump that gdb was supposed to read. But IIRC that >> ended up being more trouble than it was worth. >> > > ___ > 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] Rust language support question
> "Jim" == Jim Ingham writes: Jim> I naively thought this would make support for Rust weak, but folks Jim> on Stack Overflow say it actually works pretty well for viewing Jim> variables (using "frame var" or lldb's ValueObject's). Stepping Jim> and so forth apparently seemed to be working okay as well. Jim> Depending on how far off this actually is, you might be able to Jim> reuse the Clang TypeSystem and do mutatis mutandis for the Jim> differences? That would certainly be a lot simpler than inventing Jim> another type representation. I'm already pretty far down the road of having a type implementation for Rust. You can see the work in progress here: https://github.com/tromey/lldb/tree/rust I took this approach because Rust really does need its own system. For example the changes coming for better handling Rust enums will end up using DWARF constructs (DW_TAG_variant) that don't appear in C++. There are other differences, too. And BTW if anyone is going to FOSDEM, I'll be talking about this there. Jim> Another little quirk of lldb that might affect your planning is that Jim> unlike gdb, we don't have full calling-convention emulation in lldb at Jim> present. Thanks. I was aware of this but hadn't looked into the details yet. Jim> The way we get around this in lldb is that we marshal the inputs to Jim> the expression as well as the return type into an lldb-defined struct Jim> we cons up for the expression. Then we write a wrapper function that Jim> contains the expression but uses the input values from the argument Jim> struct. That way we only need to call a function that gets passed in Jim> a pointer to this argument struct, which tends to be pretty easy to Jim> do. Then we JIT and insert that function, create the input argument Jim> structure and call our wrapper function. Is this an approach I could take as well? I guess my plugin could convert expressions to LLVM code easily enough. Or even C I suppose. Tom ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Rust language support question
> "Pavel" == Pavel Labath writes: Pavel> To these very insightful emails from Greg and Jim, I'd just like to Pavel> add one request. Please consider the testing strategy of the code you Pavel> write early on. One of the problems that we have with these language Pavel> plugins (and why we now have a separate thread considering removal of Pavel> some of them) is that after the plugin has landed and some time has Pavel> elapsed with no activity on it, we have no idea if it is even still Pavel> functional without any tests. So far I've added code in packages/Python/lldbsuite/test to support Rust and then I have a simple Rust program that exercises the various features of the plugin. The Rust toolchain is very easy to install, so I don't think testing this in the future should be too difficult. I am not sure of the details yet, but for expression parsing, I would like to get the external helper into "rustup" (the Rust toolchain manager) as well. Pavel> (maybe via llvm/DWARFYAML) What is a good resource for learning about this? Tom ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] display register fields?
Is there a way to define and display register fields, like gdb? Or would this need to be done in python? Example: (gdb) p/x $vac0 $3 = {value = 0xedcba111, fields = {LENGTH = 0x111, SRC4_BANK = 0xa, SRC3_BANK = 0xb, SRC2_BANK = 0xc, SRC1_BANK = 0xd, DEST1_BANK = 0xe}} -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] display register fields?
There isn't a built-in way to do this. It would be nice to have "register {format, summary, synthetic children} add {provider}" in parallel with the "type {format/summary/synthetic} add". The registers come to us as value objects so it would be straightforward to hook them up, and the various ways of providing the formats should be exactly the same. Jim > On Jan 29, 2018, at 12:08 PM, Ted Woodward via lldb-dev > wrote: > > Is there a way to define and display register fields, like gdb? Or would > this need to be done in python? > > Example: > (gdb) p/x $vac0 > $3 = {value = 0xedcba111, fields = {LENGTH = 0x111, SRC4_BANK = 0xa, > SRC3_BANK = 0xb, > SRC2_BANK = 0xc, SRC1_BANK = 0xd, DEST1_BANK = 0xe}} > > > -- > Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > > > ___ > 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] display register fields?
Two way you can do this, the easy way, and the hard way. The easy way is to allow a register to define a summary string that can be attached to itself, just like "type summary add ...", but there is no typename to associate here, you just give the summary a unique name. Type summaries allow you to access bits of an integer using the "[]" operator. So if you have a variable that is an integer, then you can do have a summary string of "bit zero = ${var[0]}". This will show bit zero of the ${var} which in this case is your register. Since we hand out register values in lldb_private::ValueObject objects, and lldb::SBValue through the API, it would be easy to just give the lldb_private::ValueObject a summary when a RegisterInfo has one. If you want to access more that one bit, you can use "low nibble = ${var[0-3]}". So this would easily allow you to add a summary to any register. "type summary add" also has a "--name" option that allows you to name the summary. So if you uniquely name your register summary string with something like: (lldb) type summary add --summary-string "N=${var[31]} Z=${var[30]} C=${var[29]} V=${var[28]}" --name register.arm.cpsr Then you can always just give your register's value object the summary by name just like: (lldb) frame variable --summary register.arm.cpsr argc (int) argc = 1 N=0 Z=0 C=0 V=0 The drawback of the summary approach is you can to something like: (lldb) expr $cpsr.N The hard way would be to actually define a CompilerType for the register and somehow attach it to the value object for the register when you hand them out. The benefit of this is the expression above would work and the fields could be accessed. This means your register context would need to create a CompilerType from scratch and register it with the Target's type system for a specific language. This could be made easier by having a register value just write a blurb or C code like: const char *CPSRType_code = "struct CPSRType { uint32_t N:1, Z:1, C:1, V:1; };" Then we ask the target to create a type from code: CompilerType reg_type = target.CreateTypeFromCode(CPSRType_code, "CPSRType", eLanguageC); This would use the code in "CPSRType_code" and compile it and grab the type from the compiled code named "CPSRType" and it would compile it in C so the resulting CompilerType would be clang based. The benefit of this is your code could contain enum values and multiple types. Think of the real definition for a complete CPSR for ARM: const char *CPSRType_code = " namespace arm { enum Mode { User = 0x10, FIQ = 0x11, IRQ = 0x12, SVC = 0x13, Abort = 0x17, Undefined = 0x1b, System = 0x1f }; struct CPSRType { uint32_t N:1, Z:1, C:1, V:1; Mode mode; }; } " This would allow us to define "arm::Mode" as an enum and have that enum in a struct named "arm::CPSRType" and then put them all together: CompilerType t = target.CreateTypeFromCode(CPSRType_code, "arm::CPSRType", eLanguageC); Then attach the type "t" to your lldb_private::ValueObject for your register. Greg Clayton > On Jan 29, 2018, at 12:08 PM, Ted Woodward via lldb-dev > wrote: > > Is there a way to define and display register fields, like gdb? Or would > this need to be done in python? > > Example: > (gdb) p/x $vac0 > $3 = {value = 0xedcba111, fields = {LENGTH = 0x111, SRC4_BANK = 0xa, > SRC3_BANK = 0xb, > SRC2_BANK = 0xc, SRC1_BANK = 0xd, DEST1_BANK = 0xe}} > > > -- > Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > > > ___ > 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] February LLVM bay-area social is this Thursday!
We'll be at Tied House as usual, starting on Thursday the 1st at 7pm! If you can, help us plan and RSVP here: https://www.meetup.com/LLVM-Bay-Area-Social/events/kncsjlyxdbcb/ See everyone there! ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev