applied: https://github.com/crash-utility/crash/commit/141d5421f907395c23b5ca9a6d9f856e91e3f98a
On Wed, Nov 12, 2025 at 3:39 PM lijiang <[email protected]> wrote: > > On Wed, Nov 12, 2025 at 10:17 AM Tao Liu <[email protected]> wrote: >> >> Hi lianbo, >> >> On Tue, Nov 11, 2025 at 4:14 PM lijiang <[email protected]> wrote: >> > >> > On Wed, Nov 5, 2025 at 5:42 PM <[email protected]> >> > wrote: >> >> >> >> Date: Tue, 4 Nov 2025 12:44:38 +1300 >> >> From: Tao Liu <[email protected]> >> >> Subject: [Crash-utility] [PATCH] gdb: set req->typecode when type >> >> resolvation success >> >> To: [email protected] >> >> Cc: Tao Liu <[email protected]> >> >> Message-ID: <[email protected]> >> >> 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 <[email protected]> >> >> --- >> >> 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 >> -- Crash-utility mailing list -- [email protected] To unsubscribe send an email to [email protected] https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/ Contribution Guidelines: https://github.com/crash-utility/crash/wiki
