<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Two way you can do this, the easy way, and the hard way.<div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">(lldb) type summary add --summary-string "N=${var[31]} Z=${var[30]} C=${var[29]} V=${var[28]}" --name register.arm.cpsr</div><div class=""><br class=""></div><div class="">Then you can always just give your register's value object the summary by name just like:</div><div class=""><br class=""></div><div class="">(lldb) frame variable --summary register.arm.cpsr argc<br class="">(int) argc = 1 N=0 Z=0 C=0 V=0<br class=""><br class=""></div><div class="">The drawback of the summary approach is you can to something like:</div><div class="">(lldb) expr $cpsr.N</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">const char *CPSRType_code = "struct CPSRType { uint32_t N:1, Z:1, C:1, V:1; };"</div><div class=""><br class=""></div><div class="">Then we ask the target to create a type from code:</div><div class=""><br class=""></div><div class="">CompilerType reg_type = target.CreateTypeFromCode(CPSRType_code, "CPSRType", eLanguageC);</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">const char *CPSRType_code = "</div><div class="">namespace arm {</div><div class=""> enum Mode { <span style="font-family: sans-serif; font-size: 12.800000190734863px; text-align: center; background-color: rgb(255, 255, 255);" class="">User = 0x10, </span><span style="font-family: sans-serif; font-size: 12.800000190734863px; text-align: center; background-color: rgb(255, 255, 255);" class="">FIQ = 0x11, IRQ = 0x12, SVC = 0x13, Abort = 0x17, Undefined = 0x1b, System = 0x1f };</span></div><div style="text-align: center;" class=""><br class=""></div><div class=""> struct CPSRType { </div><div class=""> uint32_t N:1, Z:1, C:1, V:1; </div><div class=""> Mode mode;</div><div class=""> };</div><div class="">}</div><div class="">"</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">CompilerType t = target.CreateTypeFromCode(CPSRType_code, "arm::CPSRType", eLanguageC);</div><div class=""><br class=""></div><div class="">Then attach the type "t" to your lldb_private::ValueObject for your register.</div><div class=""><br class=""></div><div class="">Greg Clayton</div><div class=""><div><blockquote type="cite" class=""><div class="">On Jan 29, 2018, at 12:08 PM, Ted Woodward via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Is there a way to define and display register fields, like gdb? Or would<br class="">this need to be done in python?<br class=""><br class="">Example:<br class="">(gdb) p/x $vac0<br class="">$3 = {value = 0xedcba111, fields = {LENGTH = 0x111, SRC4_BANK = 0xa,<br class="">SRC3_BANK = 0xb,<br class=""> SRC2_BANK = 0xc, SRC1_BANK = 0xd, DEST1_BANK = 0xe}}<br class=""><br class=""><br class="">--<br class="">Qualcomm Innovation Center, Inc.<br class="">The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a<br class="">Linux Foundation Collaborative Project<br class=""><br class=""><br class="">_______________________________________________<br class="">lldb-dev mailing list<br class=""><a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev<br class=""></div></div></blockquote></div><br class=""></div></body></html>