Community
Participate
Working Groups
Created attachment 252411 [details] Sample code. Hi Eugene, The attached executable (for Linux) is an ADA program with packed array. I'm currently trying to display the values for pack__packed_obj8, pack__packed_obj16, etc .. (see testcase.py). IDE is not able to display the correct value. (I'm stopped in the bar function) I think it's because there is no support for DW_AT_bit_stride tag. Thanks ! Xavier.
Hi Eugene, I've taken a closer look. Before tacking pack__packed_comps3 which is really complex for me, I've started with pack__packed_obj8. I've tried to change "op_index" in expression.c : it badly computes the @ of the fields because of v->address += offs. I've changed get_symbol_props in order to retrieve the AT_bit_stride on the original_type. If I have an bit_stride, then I compute the address like this: v->address += offs / (v->size * 8 / props.bit_stride). Now, I have the @ correct for the field but the IDE displays the byte rather than the "decyphered" bit. So I've tried to implement a method "set_packed_value" called by op_index. That method does call load_value(v) and does the computation to decypher the value but to return the computed value, I have to set v->remote = 0. In such case, the IDE displays the bit correcly but it won't display anymore the @ of the field in the detailled pane. Moreover, it doesn't work well on packed__pack_obj16/32/64/128, probably because I don't handle the endianness in a correct manner. And for displaying a more complex structure like pack__packed_comps3, it just doesn't work. So i'm probably heading in the wrong direction. What would be the correct approach ? Thanks !
Stride support needs UI changes. Fixed. Thanks!
Hi Eugene, Great ! Many thanks ! It works great for pack__packed_objX and packed__packed_comps3. However, there are issue for more complex types like: pack__a pack__a_short pack__a_long pack__xp pack__yo These types have "packed" objects not being boolean but rather signed types or other complexes types. (I'm stopped in pack.adb:5) If I look at a_short, we do have: <1><7aa>: Abbrev Number: 4 (DW_TAG_array_type) <7ab> DW_AT_name : (indirect string, offset: 0xeac): pack__T60s <7af> DW_AT_bit_stride : 6 <7b0> DW_AT_type : <0x761> <1><761>: Abbrev Number: 8 (DW_TAG_subrange_type) <762> DW_AT_lower_bound : 0xffffffffffffffe0 <76a> DW_AT_upper_bound : 31 <76b> DW_AT_name : (indirect string, offset: 0xb83): pack__item <76f> DW_AT_type : <0x773> <1><773>: Abbrev Number: 9 (DW_TAG_base_type) <774> DW_AT_byte_size : 1 <775> DW_AT_encoding : 5 (signed) <776> DW_AT_name : (indirect string, offset: 0xd40): pack__TitemB <77a> DW_AT_artificial : 1 For a[0], IDE displays pack_item so value displayed is "raw" value (whose value has more than the number of stride bits) instead of the "inner type". Best Regards, Xavier !
Your comment is not completely clear. I assume you mean missing sign extension. I have committed a fix for that.
Created attachment 252618 [details] Screenshot
Hi Eugene, I've tried your fix. Yes, there is an improvement on pack__xp but look at pack__a_short and pack__yp (I've attached a screenshot). If I look at pack__a_short: The testsuite expects the following: A_Short : Packed_Unc_Type := (-32, -1, 0, 1, 31); Look at the values displayed. They don't match. As a user, I would expect to see in the IDE: Name Type Value [0] -31 [1] -1 Type should be pack__TitemB ? That's what I called "decyphered inner type". They are decyphered in a sense that they fit on 6 bits. "inner type" to get the signed type. It's probably not just a signed stuff : I think the "inner" type could be anything. <7af> DW_AT_bit_stride : 6 <7b0> DW_AT_type : <0x761> <7b4> DW_AT_sibling : <0x7c0> <1><761>: Abbrev Number: 8 (DW_TAG_subrange_type) <762> DW_AT_lower_bound : 0xffffffffffffffe0 (I guess -31) <76a> DW_AT_upper_bound : 31 <76b> DW_AT_name : (indirect string, offset: 0xb83): pack__item <76f> DW_AT_type : <0x773> <1><773>: Abbrev Number: 9 (DW_TAG_base_type) <774> DW_AT_byte_size : 1 <775> DW_AT_encoding : 5 (signed) <776> DW_AT_name : (indirect string, offset: 0xd40): pack__TitemB <77a> DW_AT_artificial : 1 Same remark applies for pack__small. Thanks ! Xavier.
PS : If you opened in the IDE the pack__xp, there is the same issue: y[1] is type pack_small and value is '?'. As a user, I would expect the value to be -1. In other words, if you some handling of bit_stride has been done, I think the type should be the "inner" one and value should be properly displayed. Thanks !
Created attachment 252755 [details] Screenshot
> Look at the values displayed. They don't match. They look fine to me, see attached screenshot. > I think the type should be the "inner" one and value should be properly displayed. I'm not sure what you mean. I guess, you mean the array elements are interpreted as ASCII characters in the Value column - the debugger GUI cannot distinguish 1-byte int from char. This is not perfect, but it has absolutely nothing to do with AT_bit_stride.
Hi Eugene, I think my LunaSR2 has right TCF version with your changes (see, it displays "Stride in bold". org.eclipse.tcf.debug.ui (1.3.0.201504212019) "TCF/Eclipse Debugger Integration UI" [Active] My agent is updated too. Despite those, and setting the Decimal column, I don't see the signed values. Any idea ? I would suspect I need another dependency on Expression view because I don't see in your Java code where the lowerbound is handled in TCFNodeExpression.java ? > I guess, you mean the array elements are interpreted as ASCII characters in the Value column Exactly. As a user, I would expect Value to "understand that the value fits on 6 bits, has a lower bound, is signed" so the right value would be displayed. I agree it has nothing to do with AT_bit_stride but those complex types are "hard to display / interpret" for a client tool. It would be great if the expression service could do more processing on such complex types and returns the "processed value" (that takes in account the fact it is signed, fits on 6 bits, has lower bound) rather than having the client tool do it (so I guess that's why I don't see the right value, my client tool lunasr2 is probably incompletely updated). I'm not sure a user would think to select the "Decimal column". Thanks ! Xavier.
Created attachment 252779 [details] Not seeing the right signed value.
> My agent is updated too. Oops, I forgot to commit agent changes. Sorry about that. It should work now. > It would be great if the expression service could do more processing on such complex types and returns the "processed value" (that takes in account the fact it is signed, fits on 6 bits, has lower bound)... Yes, it does that. GUI tries to figure out array element values locally as an optimization, which substantially reduces traffic. You don't have to do same in your tool. You can rely on the Expressions service to compute array elements.
Hi Eugene, Ok thanks. I understand your 2 replies, thanks for the fix in expressions.c. In expression.c, I have a build warning (leading to build failure with our settings) due to this in op_index. uint8_t * buf = (uint8_t *)tmp_alloc_zero(size); Could you please add this cast to fix the build ? uint8_t * buf = (uint8_t *)tmp_alloc_zero((size_t) size); Thanks ! Xavier.
Fixed the warning. Closing as resolved/fixed. Thanks!
Great ! Thanks.
