On Wed, Nov 12, 2025 at 10:17 AM Tao Liu <ltao@redhat.com> wrote:
Hi lianbo,

On Tue, Nov 11, 2025 at 4:14 PM lijiang <lijiang@redhat.com> wrote:
>
> On Wed, Nov 5, 2025 at 5:42 PM <devel-request@lists.crash-utility.osci.io> wrote:
>>
>> Date: Tue,  4 Nov 2025 12:44:38 +1300
>> From: Tao Liu <ltao@redhat.com>
>> Subject: [Crash-utility] [PATCH] gdb: set req->typecode when type
>>         resolvation success
>> To: devel@lists.crash-utility.osci.io
>> Cc: Tao Liu <ltao@redhat.com>
>> Message-ID: <20251103234438.58969-1-ltao@redhat.com>
>> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>>
>> In gdb_get_datatype(), the req->typecode is set as TYPE_CODE_UNDEF, and
>> it won't be set to other value in OP_TYPE case. If the type doesn't exist,
>> it will bail out in parse_expression() by exception catch of gdb_command_funnel(),
>> and req->typecode stays TYPE_CODE_UNDEF, which is expected. But if the type is
>> exist, it will be resolved by drillDownType(), so req->typecode shouldn't be
>> TYPE_CODE_UNDEF anymore, otherwise upper functions will regard this as a type
>> resolvation failure.
>
>
> Do you know what type it is here? In gdb 16.2, the type code has been extended(see: gdb-16.2/gdb/type-codes.def).
>
Sorry I didn't get your point. The drillDownType() will resolve the
types, no matter it is a TYPE_CODE_PTR/INT/STRUCT etc. So the
req->typecode shouldn't be left as TYPE_CODE_UNDEF. This bug is found
for testing "sizeof(struct task_struct)" in eppic script. So
drillDownType() is responsible for resolving task_struct and it is
TYPE_CODE_STRUCT, this is included in gdb-16.2/gdb/type-codes.def. I

This answered my question, thank you for the explanation.
I'm afraid of the new(or unknown) type in gdb-16.2/gdb/type-codes.def, but not defined in defs.h(enum type_code{}).
 Here, It is TYPE_CODE_STRUCT, which looks like a different issue.

For the patch, I have no other issues, so: Ack.

Lianbo

don't know if it answers your question.

Thanks,
Tao Liu

> Thanks
> Lianbo
>
>>
>>
>> This issue only affects eppic extensions because currently the only user
>> of req->tcb is eppic.
>>
>> Signed-off-by: Tao Liu <ltao@redhat.com>
>> ---
>>  gdb-16.2.patch | 10 ++++++++++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/gdb-16.2.patch b/gdb-16.2.patch
>> index 6767bf7..78cf605 100644
>> --- a/gdb-16.2.patch
>> +++ b/gdb-16.2.patch
>> @@ -2000,3 +2000,13 @@ exit 0
>>     /* This may be a static executable.  Look for the symbol
>>        conventionally named _r_debug, as a last resort.  */
>>     bound_minimal_symbol msymbol
>> +--- gdb-16.2/gdb/symtab.c.orig
>> ++++ gdb-16.2/gdb/symtab.c
>> +@@ -7726,6 +7726,7 @@
>> +                     type = expr->evaluate_type()->type();
>> +
>> +                 if (req->tcb) {
>> ++                        req->typecode = TYPE_CODE(type);
>> +                         drillDownType(req, type);
>> +                 } else {
>> +                         req->typecode = TYPE_CODE(type);
>> --
>> 2.47.0