This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [David Carlton <carlton@math.Stanford.EDU>] Re: [RFA] dwarf2read.c: set TYPE_DOMAIN_TYPE correctly for methods
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: David Carlton <carlton at math dot stanford dot edu>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Wed, 28 Aug 2002 18:42:47 -0400
- Subject: Re: [David Carlton <carlton@math.Stanford.EDU>] Re: [RFA] dwarf2read.c: set TYPE_DOMAIN_TYPE correctly for methods
- References: <ro17kiahb81.fsf@jackfruit.Stanford.EDU>
On Wed, Aug 28, 2002 at 03:25:50PM -0700, David Carlton wrote:
> Here's a ping for a patch that I'd like to get in before the 5.3
> branch is cut; I'm sending the ping now even though I originally sent
> the patch out just under a week ago because I'll be out of the office
> through next Monday. (I'm not this pushy normally, honest.)
>
> The reason why I want to get this into the 5.3 branch is because it
> fixes a seg fault and seg faults make me unduly nervous. :-)
My judgement would be that this fixes an obvious mistake in my previous
patch.
> @@ -2327,7 +2328,15 @@ dwarf2_add_member_fn (struct field_info
> struct type *return_type = TYPE_TARGET_TYPE (die->type);
> int nparams = TYPE_NFIELDS (die->type);
>
> - smash_to_method_type (fnp->type, die->type,
> + /* NOTE: carlton/2002-08-22: Previously, the second argument to
> + smash_to_method_type was die->type rather than type, and the
> + type argument to dwarf2_add_member_fn didn't exst. This is
> + incorrect: the second argument to smash_to_method_type should
> + be the type of the class that this is a method of, whereas
> + die->type is the type of the method itself. So we need to
> + pass that type in from read_structure_scope explicitly. See
> + PR gdb/653. */
> + smash_to_method_type (fnp->type, type,
> TYPE_TARGET_TYPE (die->type),
> TYPE_FIELDS (die->type),
> TYPE_NFIELDS (die->type),
I'd rather a comment like:
/* TYPE is the domain of this method, and DIE->TYPE is the type
of the method itself (TYPE_CODE_METHOD). */
There's no point in cluttering up the code with history of this sort
unless you have low confidence in the change's effect on some odd
corner-case. That's just my personal judgement, though.
If you agree, mind committing it with that or a similar change?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer