From: Joel Brobecker <brobecker@adacore.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org, Tobias Burnus <burnus@net-b.de>,
Ulrich Weigand <uweigand@de.ibm.com>,
Jim Blandy <jimb@red-bean.com>
Subject: Re: [patch] static_kind -> bit0, bit1 [Re: [gdb] Fortran dynamic arrays]
Date: Mon, 06 Oct 2008 20:00:00 -0000 [thread overview]
Message-ID: <20081006200001.GC3588@adacore.com> (raw)
In-Reply-To: <20081004202457.GA20726@host0.dyn.jankratochvil.net>
> 2008-10-04 Jan Kratochvil <jan.kratochvil@redhat.com>
>
> Convert static_kind into loc_kind enum.
[...]
Thanks for the patch. I have a few tiny comments left, but the principle
looks good to me.
> --- gdb/gdbtypes.h 2 Oct 2008 22:06:07 -0000 1.92
> +++ gdb/gdbtypes.h 4 Oct 2008 19:44:27 -0000
> @@ -316,6 +316,16 @@ enum type_instance_flag_value
> #define TYPE_ADDRESS_CLASS_ALL(t) (TYPE_INSTANCE_FLAGS(t) \
> & TYPE_INSTANCE_FLAG_ADDRESS_CLASS_ALL)
>
> +/* Determine which field of the union main_type.fields[x].loc is used. */
> +
> +enum field_loc_kind
> + {
> + FIELD_LOC_KIND_BITPOS, /* bitpos */
Is it worth forcing the value of FIELD_LOC_KIND_BITPOS to zero?
FIELD_LOC_KIND_BITPOS = 0,
(this is where my lack of knowledge of C shows up)
> + /* For variable length arrays. Passed to dwarf_locexpr_baton_eval. */
> + struct dwarf2_locexpr_baton *dwarf_block;
I would prefer a more generic explaination, because this could
be used in any situation where the field location is not known
at compile time.
/* The field location can be computed by evaluating the following
DWARF block. This can be used in Fortran variable-length
arrays, for instance. */
> +#define FIELD_STATIC(thisfld) \
> + (FIELD_LOC_KIND (thisfld) == FIELD_LOC_KIND_PHYSNAME \
> + || FIELD_LOC_KIND (thisfld) == FIELD_LOC_KIND_PHYSADDR)
With the new scheme, this is no longer an accessor macro, but more like
a logical deduction based on field.loc_kind. So I suggest we implement
it as a function instead rather than following the accessor-macro style.
In theory, using the loc discriminant seems a little iffy to me, compared
to having a dedicated flag for that. But it'll work in practice, at least
for now. Back to the function, I propose:
int
field_is_static (struct field *f)
{
/* "static" fields are the fields whose location is not relative
to the address of the enclosing struct. It would be nice to
have a dedicated flag that would be set for static fields when
the type is being created. But in practice, checking the field
loc_kind should give us an accurate answer (at least as long as
we assume that DWARF block locations are not going to be used
for static fields). FIXME? */
return (FIELD_LOC_KIND (*f) == FIELD_LOC_KIND_PHYSNAME
|| FIELD_LOC_KIND (*f) == FIELD_LOC_KIND_PHYSADDR);
}
> +#define TYPE_FIELD_STATIC(thistype, n) FIELD_STATIC (TYPE_FIELD (thistype, n))
If we implement field_is_static, then I propose we delete this macro
entirely.
> --- gdb/dwarf2read.c 30 Sep 2008 16:57:37 -0000 1.285
> +++ gdb/dwarf2read.c 4 Oct 2008 19:44:18 -0000
> @@ -3561,8 +3561,6 @@ dwarf2_add_field (struct field_info *fip
One interesting consequence of your change is that it should help
when we want to deal with fields whose position is described with
a location list.
> /* Get type of field. */
> fp->type = die_type (die, cu);
>
> - FIELD_STATIC_KIND (*fp) = 0;
[...]
> -
> /* Get bit size of field (zero if none). */
> attr = dwarf2_attr (die, DW_AT_bit_size, cu);
> if (attr)
> @@ -3590,10 +3588,10 @@ dwarf2_add_field (struct field_info *fip
> else
> byte_offset = decode_locdesc (DW_BLOCK (attr), cu);
>
> - FIELD_BITPOS (*fp) = byte_offset * bits_per_byte;
> + SET_FIELD_BITPOS (*fp, byte_offset * bits_per_byte);
> }
> else
> - FIELD_BITPOS (*fp) = 0;
> + SET_FIELD_BITPOS (*fp, 0);
Can we replace the "FIELD_STATIC_KIND = 0" line by "SET_FIELD_BITPOS
(*fp, 0);" and then remove the "else" part below? I am convinced that
your change is correct, and the kind will always be set because it is
set in both branches of the "if/else", but this way feels safer against
future changes.
--
Joel
next prev parent reply other threads:[~2008-10-06 20:00 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-15 15:06 [gdb] Fortran dynamic arrays Tobias Burnus
2008-08-18 11:12 ` Joel Brobecker
2008-08-18 15:54 ` Ulrich Weigand
2008-09-07 11:59 ` [patch] static_kind -> bit0, bit1 [Re: [gdb] Fortran dynamic arrays] Jan Kratochvil
2008-09-08 15:32 ` Tom Tromey
2008-09-08 17:27 ` Jan Kratochvil
2008-09-19 22:29 ` Joel Brobecker
2008-09-26 23:04 ` Tom Tromey
2008-09-27 14:53 ` Joel Brobecker
2008-09-19 6:04 ` Joel Brobecker
2008-09-22 15:25 ` Jan Kratochvil
2008-09-24 19:15 ` Joel Brobecker
2008-09-26 5:03 ` Jan Kratochvil
2008-09-26 22:12 ` Joel Brobecker
2008-10-02 22:13 ` [patch] Fortran obsolete bounds type [Re: [patch] static_kind -> bit0, bit1] Jan Kratochvil
2008-09-26 12:52 ` [patch] static_kind -> bit0, bit1 [Re: [gdb] Fortran dynamic arrays] Daniel Jacobowitz
2008-09-26 22:15 ` Joel Brobecker
2008-09-26 22:20 ` Daniel Jacobowitz
2008-09-19 22:13 ` Joel Brobecker
2008-09-26 5:06 ` Accessor macro wrappers removal [Re: [patch] static_kind -> bit0, bit1] Jan Kratochvil
2008-09-26 12:55 ` Daniel Jacobowitz
2008-10-02 20:59 ` Jan Kratochvil
2008-10-02 21:05 ` Daniel Jacobowitz
2008-09-26 23:15 ` Tom Tromey
2008-09-26 12:58 ` [patch] static_kind -> bit0, bit1 [Re: [gdb] Fortran dynamic arrays] Daniel Jacobowitz
[not found] ` <20081006200928.GD3588@adacore.com>
2008-10-06 20:26 ` Jan Kratochvil
2008-10-07 23:22 ` type/main_type/field size [Re: [patch] static_kind -> bit0, bit1] Jan Kratochvil
2008-10-08 3:32 ` Joel Brobecker
2008-10-08 23:56 ` Tom Tromey
2008-10-04 20:28 ` [patch] static_kind -> bit0, bit1 [Re: [gdb] Fortran dynamic arrays] Jan Kratochvil
2008-10-06 20:00 ` Joel Brobecker [this message]
2008-10-07 23:18 ` Jan Kratochvil
2008-10-08 3:28 ` Joel Brobecker
2008-10-08 12:54 ` Jan Kratochvil
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=20081006200001.GC3588@adacore.com \
--to=brobecker@adacore.com \
--cc=burnus@net-b.de \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=jimb@red-bean.com \
--cc=uweigand@de.ibm.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