From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
To: "'Doug Evans'" <xdje42@gmail.com>, <gdb-patches@sourceware.org>,
<gaius@glam.ac.uk>
Subject: RE: [PATCH 4/5] Remove struct main_type.vptr_{fieldno,basetype}: TYPE_SPECIFIC_SELF_TYPE
Date: Thu, 05 Feb 2015 17:37:00 -0000 [thread overview]
Message-ID: <00db01d0416a$5a9be790$0fd3b6b0$@muller@ics-cnrs.unistra.fr> (raw)
In-Reply-To: <m3twze8kxc.fsf@sspiff.org>
Hi all,
> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Doug Evans
> Envoyé : lundi 26 janvier 2015 01:07
> À : gdb-patches@sourceware.org; gaius@glam.ac.uk
> Objet : [PATCH 4/5] Remove struct main_type.vptr_{fieldno,basetype}:
> TYPE_SPECIFIC_SELF_TYPE
>
> Hi.
>
> This patch moves TYPE_SELF_TYPE into new field type_specific.self_type
> for MEMBERPTR,METHODPTR types, and into type_specific.func_stuff
> for METHODs, and then updates everything to use that.
> TYPE_CODE_METHOD could share some things with TYPE_CODE_FUNC
> (e.g. TYPE_NO_RETURN) and it seemed simplest to keep them together.
>
> Moving TYPE_SELF_TYPE into type_specific.func_stuff for
> TYPE_CODE_METHOD
> is also nice because when we allocate space for function types we
> assume
> they're TYPE_CODE_FUNCs. If TYPE_CODE_METHODs don't need or use that
> space then that space would be wasted, and cleaning that up would
> involve
> more invasive changes.
>
> In order to catch errant uses I've added accessor functions
> that do some checking.
>
> One can no longer assign to TYPE_SELF_TYPE like this:
>
> TYPE_SELF_TYPE (foo) = bar;
>
> One instead has to do:
>
> set_type_self_type (foo, bar);
>
> But I've left reading of the type to the macro:
>
> bar = TYPE_SELF_TYPE (foo);
>
> I could add SET_TYPE_SELF_TYPE as a wrapper on set_type_self_type
> if you prefer that.
>
> In order to discourage bypassing the TYPE_SELF_TYPE macro
> I've named the underlying function that implements it
....
> * stabsread.c (read_member_functions): Mark methods with
> TYPE_CODE_METHOD, not TYPE_CODE_FUNC. Update setting of
> TYPE_SELF_TYPE.
.....
> diff --git a/gdb/stabsread.c b/gdb/stabsread.c
> index 1f46f75..423c442 100644
> --- a/gdb/stabsread.c
> +++ b/gdb/stabsread.c
> @@ -2376,14 +2376,21 @@ read_member_functions (struct field_info *fip,
> char **pp, struct type *type,
> p++;
> }
>
> - /* If this is just a stub, then we don't have the real name
> here. */
> + /* These are methods, not functions. */
> + if (TYPE_CODE (new_sublist->fn_field.type) == TYPE_CODE_FUNC)
> + TYPE_CODE (new_sublist->fn_field.type) = TYPE_CODE_METHOD;
> + else
> + gdb_assert (TYPE_CODE (new_sublist->fn_field.type)
> + == TYPE_CODE_METHOD);
>
> + /* If this is just a stub, then we don't have the real name
> here. */
> if (TYPE_STUB (new_sublist->fn_field.type))
> {
> if (!TYPE_SELF_TYPE (new_sublist->fn_field.type))
I suspect this is the part that generates the failure
I saw when trying to test my pascal patch that used stabs debugging
information.
internal_type_self_type generates an internal error
it does not simply return NULL...
> - TYPE_SELF_TYPE (new_sublist->fn_field.type) = type;
> + set_type_self_type (new_sublist->fn_field.type, type);
> new_sublist->fn_field.is_stub = 1;
> }
> +
> new_sublist->fn_field.physname = savestring (*pp, p - *pp);
> *pp = p + 1;
The patch below removes the internal error,
but I am not sure it is the correct fix...
Maybe set_type_self_type should be called unconditionally.
Likewise, the line:
valops.c:2547: gdb_assert (TYPE_SELF_TYPE (fns_ptr[0].type) != NULL);
is not compatible with your new internal_type_self_type as this
new function never returns NULL....
Pierre Muller
$ git diff
diff --git a/gdb/stabsread.c b/gdb/stabsread.c
index 2a160c5..392fdb2 100644
--- a/gdb/stabsread.c
+++ b/gdb/stabsread.c
@@ -2386,7 +2386,7 @@ read_member_functions (struct field_info *fip, char
**pp, struct type *type,
/* If this is just a stub, then we don't have the real name here.
*/
if (TYPE_STUB (new_sublist->fn_field.type))
{
- if (!TYPE_SELF_TYPE (new_sublist->fn_field.type))
+ if (TYPE_SPECIFIC_FIELD (new_sublist->fn_field.type) ==
TYPE_SPECIFIC_NONE)
set_type_self_type (new_sublist->fn_field.type, type);
new_sublist->fn_field.is_stub = 1;
}
next prev parent reply other threads:[~2015-02-05 17:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-26 7:29 Doug Evans
2015-02-05 17:37 ` Pierre Muller [this message]
[not found] ` <54d3aa46.0660b40a.14f0.ffffeae7SMTPIN_ADDED_BROKEN@mx.google.com>
2015-02-06 7:21 ` Doug Evans
2015-02-07 17:47 ` Pierre Muller
[not found] ` <54d3aa6b.a23d460a.0d37.0908SMTPIN_ADDED_BROKEN@mx.google.com>
2015-02-07 23:06 ` Doug Evans
2015-02-08 14:48 ` Pierre Muller
[not found] ` <54d7775a.2b2c460a.5b38.7725SMTPIN_ADDED_BROKEN@mx.google.com>
2015-02-11 6:28 ` Doug Evans
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='00db01d0416a$5a9be790$0fd3b6b0$@muller@ics-cnrs.unistra.fr' \
--to=pierre.muller@ics-cnrs.unistra.fr \
--cc=gaius@glam.ac.uk \
--cc=gdb-patches@sourceware.org \
--cc=xdje42@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox