[Crash-utility] fix gdb_get_datatype cannot handle integer type

Lei Wen adrian.wenl at gmail.com
Thu Mar 7 06:42:21 UTC 2013


Dave,

On Thu, Mar 7, 2013 at 12:56 AM, Dave Anderson <anderson at redhat.com> wrote:
>
>
> ----- Original Message -----
>> Dave,
>>
>> On Wed, Mar 6, 2013 at 10:04 PM, Dave Anderson <anderson at redhat.com>
>> wrote:
>> >
>> >
>> > ----- Original Message -----
>> >> Hi Dave,
>> >>
>> >> Current when pass integer type to gdb_get_datatype in crash, it would return
>> >> req->typecode=0 and req->length=0.
>> >>
>> >> As it only allow TYPE_CODE_ENUM to be passed. here is a patch for fixing it.
>> >> Do you think it could be merged?
>> >
>> > That's the OP_VAR_VALUE section -- what is the command that you're using that
>> > ends up passing an integer type to the function?  And what problem does it
>> > cause?
>>
>> I enhance whatis command in my local code base to show the function's original variant name.
>> If not with my change, the original result is:
>> int schedule_delayed_work_on(int , struct delayed_work * , long unsigned int );
>> With my change, the result becomes:
>> int schedule_delayed_work_on(int cpu, struct delayed_work * dwork, long unsigned int delay);
>>
>> So it look nicer, right? :)
>
> I guess -- but when I add the patch, it doesn't look any different, so presumably
> it only applies w/respect to your enhanced whatis command...
>
>>
>> But I meet an issue that whatis is not intent for showing function prototype only, but for
>> structure/union/integer type.
>>
>> So I need to add arg_to_datatype in whatis_variable to tell the passed data's type to whether
>> call gdb's function for exacting out the function parameter's name.
>>
>> Then I face the bug as I reported...
>
> It's not really a bug because that code path was meant for usage by the
> enumerator_value() function.  So it makes me a bit nervous to modify it
> for code that only your enhanced whatis command would ever see.
>
> Would your code work if only the req->typecode and req->length fields where
> passed back?  (i.e., without tinkering with the req->value and req->tagname
> fields in the non-enum case?)  Like this:
>
> --- gdb-7.3.1/gdb/symtab.c.orig
> +++ gdb-7.3.1/gdb/symtab.c
> @@ -5054,8 +5054,9 @@ gdb_get_datatype(struct gnu_request *req
>                 if (gdb_CRASHDEBUG(2))
>                         console("expr->elts[0].opcode: OP_VAR_VALUE\n");
>                 type = expr->elts[2].symbol->type;
> +               req->typecode = TYPE_CODE(type);
> +               req->length = TYPE_LENGTH(type);
>                 if (TYPE_CODE(type) == TYPE_CODE_ENUM) {
> -                       req->typecode = TYPE_CODE(type);
>                         req->value = SYMBOL_VALUE(expr->elts[2].symbol);
>                         req->tagname = TYPE_TAG_NAME(type);
>                         if (!req->tagname) {
>

This seems also works for me.

> And what exactly do you pass to datatype_info() that would lead to
> that code path?

The detailed change is:
@@ -6687,11 +6687,17 @@ add_function_name(char *argnames, char *func)
 static void
 whatis_variable(struct syment *sp)
 {
+       struct datatype_member datatype_member, *dm;
        struct gnu_request *req;
        int ret;
        char *p1;
        char buf[BUFSIZE];

+       dm = &datatype_member;
+       strcpy(buf, sp->name);
+       if (!arg_to_datatype(buf, dm, RETURN_ON_ERROR|DATATYPE_QUERY))
+               return FALSE;
+

If I type the command as "whatis jiffies", it would run into the bug path.

Thanks,
Lei




More information about the Crash-utility mailing list