[lldb-dev] February LLVM bay-area social is this Thursday!

[George Burgess IV via lldb-dev]

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

Re: [lldb-dev] display register fields?

[Greg Clayton via lldb-dev]

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

Re: [lldb-dev] display register fields?

[Jim Ingham via lldb-dev]

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

[lldb-dev] display register fields?

[Ted Woodward via lldb-dev]

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] Rust language support question

[Tom Tromey via lldb-dev]

> "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

Re: [lldb-dev] Rust language support question

[Tom Tromey via lldb-dev]

> "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 Labath via lldb-dev]

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