Dave,
On Fri, Mar 8, 2013 at 4:12 AM, Dave Anderson <anderson(a)redhat.com> wrote:
----- Original Message -----
> Dave,
>
> On Thu, Mar 7, 2013 at 12:56 AM, Dave Anderson <anderson(a)redhat.com>
> wrote:
> >
> >
> > ----- Original Message -----
> >> Dave,
> >>
> >> On Wed, Mar 6, 2013 at 10:04 PM, Dave Anderson
> >> <anderson(a)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.
All right, I'll merge the patch as shown above. I cannot seem to find
another pathway to get it other than via enumerator_value(), so it
should be safe.
Thanks for accepting the patch.
Do you have any interest for my whatis changes, that is add parameter name
showing for function symbol?
If yes, I also could make a patch for it.
Thanks,
Lei