From: "Aktemur, Baris" <TankutBaris.Aktemur@amd.com>
To: Tom Tromey <tom@tromey.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: RE: [PATCH 05/16] gdb: inline address_space_{name, type_instance_flags}_to_{type_instance_flags, name}
Date: Wed, 22 Jul 2026 10:29:17 +0000 [thread overview]
Message-ID: <DM4PR12MB6470DA0E1F04F907C299F36DF8C12@DM4PR12MB6470.namprd12.prod.outlook.com> (raw)
In-Reply-To: <87fr1ctcv6.fsf@tromey.com>
AMD General
Hi Tom,
Thank you for your review.
On Tuesday, July 21, 2026 8:30 PM, Tom Tromey wrote:
...
> > + enum type_pieces piece;
> > + int int_val;
> > + unsigned int aclass;
> > +
> > + /* Check for Harvard address space delimiters. */
> > + if (streq (string, "code"))
> > + {
> > + piece = tp_harvard_aspace_identifier;
> > + int_val = TYPE_INSTANCE_FLAG_CODE_SPACE;
> > + }
> > + else if (streq (string, "data"))
> > + {
> > + piece = tp_harvard_aspace_identifier;
> > + int_val = TYPE_INSTANCE_FLAG_DATA_SPACE;
> > + }
> > + else if (gdbarch_address_class_name_to_id_p (gdbarch)
> > + && gdbarch_address_class_name_to_id (gdbarch,
> > + string,
> > + aclass))
> > + {
> > + piece = tp_aclass_identifier;
> > + int_val = (enum type_instance_flag_value) (aclass << 4);
> > + }
> > + else
> > + error (_("Unknown address space/class specifier: \"%s\""), string);
> > +
> > + element.piece = piece;
> > insert_into (slot, element);
> > - element.int_val
> > - = address_space_name_to_type_instance_flags (gdbarch, string);
> > + element.int_val = int_val;
>
> I think the various 'if' branches might as well just assign directly to
> element.*; and 'aclass' can be moved into the if like
>
> else if (unsigned int aclass = 0;
> gdbarch_address_class_name_to_id_p (...)
> && ...)
I had chosen to write it the way I posted because we're inserting
two elements back-to-back, which are of different union kinds.
Looking at the code again based on your comments, I think we can
do better if we have an overload of the insert_into method. I'm
adding a new refactoring patch and this patch will look better
based on that, IMHO. Please check in v2.
>
> I didn't read the whole series yet but if we're going to use different
> words, as is done in that error message, then some spot in the manual
> ought to explain this.
I went through the GDB manual, and I don't see address classes or Harvard
address spaces described anywhere. The built-in `@code` and `@data` syntax
is also not explained. This seems to be a gap in the documentation.
I can write a small section for this, but let me do that in a separate
submission.
Regards,
-Baris
next prev parent reply other threads:[~2026-07-22 10:31 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-13 13:59 [PATCH 00/16] Rewrite type instance flags as a struct with bitfields Tankut Baris Aktemur
2026-07-13 14:00 ` [PATCH 01/16] gdb: use type instance macros to query const, volatile, restrict Tankut Baris Aktemur
2026-07-21 17:52 ` Tom Tromey
2026-07-13 14:00 ` [PATCH 02/16] gdb: convert address_class_type_flags_to_name to address_class_id_to_name Tankut Baris Aktemur
2026-07-21 18:03 ` Tom Tromey
2026-07-13 14:00 ` [PATCH 03/16] gdb: convert address_class_name_to_type_flags to address_class_name_to_id Tankut Baris Aktemur
2026-07-21 18:10 ` Tom Tromey
2026-07-13 14:00 ` [PATCH 04/16] gdb: convert address_class_type_flags to address_class_dwarf_to_id Tankut Baris Aktemur
2026-07-21 18:19 ` Tom Tromey
2026-07-13 14:00 ` [PATCH 05/16] gdb: inline address_space_{name, type_instance_flags}_to_{type_instance_flags, name} Tankut Baris Aktemur
2026-07-21 18:29 ` Tom Tromey
2026-07-22 10:29 ` Aktemur, Baris [this message]
2026-07-22 13:38 ` Tom Tromey
2026-07-13 14:00 ` [PATCH 06/16] gdb: split make_type_with_address_space Tankut Baris Aktemur
2026-07-21 18:49 ` Tom Tromey
2026-07-13 14:00 ` [PATCH 07/16] gdb: convert type instance flags to bitfields Tankut Baris Aktemur
2026-07-21 19:13 ` Tom Tromey
2026-07-22 10:29 ` Aktemur, Baris
2026-07-13 14:00 ` [PATCH 08/16] gdb: convert TYPE_NOTTEXT macro to type::is_nottext Tankut Baris Aktemur
2026-07-21 18:39 ` Tom Tromey
2026-07-13 14:00 ` [PATCH 09/16] gdb: convert TYPE_CONST macro to type::is_const Tankut Baris Aktemur
2026-07-21 18:40 ` Tom Tromey
2026-07-13 14:00 ` [PATCH 10/16] gdb: convert TYPE_VOLATILE macro to type::is_volatile Tankut Baris Aktemur
2026-07-13 14:00 ` [PATCH 11/16] gdb: convert TYPE_CODE_SPACE macro to type::is_code_space Tankut Baris Aktemur
2026-07-13 14:00 ` [PATCH 12/16] gdb: convert TYPE_DATA_SPACE macro to type::is_data_space Tankut Baris Aktemur
2026-07-13 14:00 ` [PATCH 13/16] gdb: convert TYPE_RESTRICT macro to type::is_restrict Tankut Baris Aktemur
2026-07-13 14:00 ` [PATCH 14/16] gdb: convert TYPE_ATOMIC macro to type::is_atomic Tankut Baris Aktemur
2026-07-13 14:00 ` [PATCH 15/16] gdb: convert TYPE_ADDRESS_CLASS macro to type::address_class Tankut Baris Aktemur
2026-07-13 14:00 ` [PATCH 16/16] gdb: remove unnecessary braces in recursive_dump_type Tankut Baris Aktemur
2026-07-21 18:45 ` Tom Tromey
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=DM4PR12MB6470DA0E1F04F907C299F36DF8C12@DM4PR12MB6470.namprd12.prod.outlook.com \
--to=tankutbaris.aktemur@amd.com \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.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