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
