* [RFC] s390-tdep.c: Define address class functions for s390x
@ 2003-01-27 23:26 Kevin Buettner
2003-01-31 20:19 ` Jim Blandy
2003-02-03 20:46 ` Kevin Buettner
0 siblings, 2 replies; 4+ messages in thread
From: Kevin Buettner @ 2003-01-27 23:26 UTC (permalink / raw)
To: gdb-patches
The default pointer size for s390x is 64 bits. The patch below causes
32-bit pointer types obtained from (dwarf2) debug info to be stored as
a separate type and to be qualified (in gdb's ptype output) as
"@mode32". [Patches to gdbtypes.[hc] and dwarf2read.c which implement
address class support have already been committed. They need to be
revisited, however, because in the course of testing out this patch, I
found a bug. More on that later...]
Comments?
* s390-tdep.c (s390_address_class_type_flags)
(s390_address_class_type_flags_to_name)
(s390_address_class_name_to_type_flags): New functions.
(s390_gdbarch_init): Define ADDRESS_CLASS_TYPE_FLAGS_TO_NAME,
ADDRESS_CLASS_NAME_TO_TYPE_FLAGS, and ADDRESS_CLASS_TYPE_FLAGS.
Index: s390-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/s390-tdep.c,v
retrieving revision 1.70
diff -u -p -r1.70 s390-tdep.c
--- s390-tdep.c 8 Jan 2003 17:21:29 -0000 1.70
+++ s390-tdep.c 27 Jan 2003 23:03:28 -0000
@@ -1748,6 +1748,37 @@ s390_push_return_address (CORE_ADDR pc,
return sp;
}
+static int
+s390_address_class_type_flags (int byte_size, int dwarf2_addr_class)
+{
+ if (byte_size == 4)
+ return TYPE_FLAG_ADDRESS_CLASS_1;
+ else
+ return 0;
+}
+
+static const char *
+s390_address_class_type_flags_to_name (struct gdbarch *gdbarch, int type_flags)
+{
+ if (type_flags & TYPE_FLAG_ADDRESS_CLASS_1)
+ return "mode32";
+ else
+ return NULL;
+}
+
+int
+s390_address_class_name_to_type_flags (struct gdbarch *gdbarch, const char *name,
+ int *type_flags_ptr)
+{
+ if (strcmp (name, "mode32") == 0)
+ {
+ *type_flags_ptr = TYPE_FLAG_ADDRESS_CLASS_1;
+ return 1;
+ }
+ else
+ return 0;
+}
+
struct gdbarch *
s390_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
{
@@ -1869,6 +1900,12 @@ s390_gdbarch_init (struct gdbarch_info i
set_gdbarch_long_long_bit (gdbarch, 64);
set_gdbarch_ptr_bit (gdbarch, 64);
set_gdbarch_register_bytes (gdbarch, S390X_REGISTER_BYTES);
+ set_gdbarch_address_class_type_flags (gdbarch,
+ s390_address_class_type_flags);
+ set_gdbarch_address_class_type_flags_to_name (gdbarch,
+ s390_address_class_type_flags_to_name);
+ set_gdbarch_address_class_name_to_type_flags (gdbarch,
+ s390_address_class_name_to_type_flags);
break;
}
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [RFC] s390-tdep.c: Define address class functions for s390x
2003-01-27 23:26 [RFC] s390-tdep.c: Define address class functions for s390x Kevin Buettner
@ 2003-01-31 20:19 ` Jim Blandy
2003-01-31 21:07 ` Kevin Buettner
2003-02-03 20:46 ` Kevin Buettner
1 sibling, 1 reply; 4+ messages in thread
From: Jim Blandy @ 2003-01-31 20:19 UTC (permalink / raw)
To: Kevin Buettner; +Cc: gdb-patches
This looks like a pretty straightforward definition of a new address
class. Is that right?
Since we only have one target using this facility at the moment, this
might be premature, but I wonder if it would be worthwhile to provide
standard, table-driven versions of *_address_class_type_flags_to_name,
and *_address_class_name_to_type_flags, so that a target could simply
say:
static address_class_table s390_addr_classes[] = {
{ "mode32", TYPE_FLAG_ADDRESS_CLASS_1 },
{ 0, 0 }
};
...
use_address_class_table_in_gdbarch (gdbarch, s390_addr_classes);
which would install the right methods. Or something like that.
Maybe even s390_address_class_type_flags could be handled by the same
table. I haven't thought it through.
Kevin Buettner <kevinb@redhat.com> writes:
> The default pointer size for s390x is 64 bits. The patch below causes
> 32-bit pointer types obtained from (dwarf2) debug info to be stored as
> a separate type and to be qualified (in gdb's ptype output) as
> "@mode32". [Patches to gdbtypes.[hc] and dwarf2read.c which implement
> address class support have already been committed. They need to be
> revisited, however, because in the course of testing out this patch, I
> found a bug. More on that later...]
>
> Comments?
>
> * s390-tdep.c (s390_address_class_type_flags)
> (s390_address_class_type_flags_to_name)
> (s390_address_class_name_to_type_flags): New functions.
> (s390_gdbarch_init): Define ADDRESS_CLASS_TYPE_FLAGS_TO_NAME,
> ADDRESS_CLASS_NAME_TO_TYPE_FLAGS, and ADDRESS_CLASS_TYPE_FLAGS.
>
> Index: s390-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/s390-tdep.c,v
> retrieving revision 1.70
> diff -u -p -r1.70 s390-tdep.c
> --- s390-tdep.c 8 Jan 2003 17:21:29 -0000 1.70
> +++ s390-tdep.c 27 Jan 2003 23:03:28 -0000
> @@ -1748,6 +1748,37 @@ s390_push_return_address (CORE_ADDR pc,
> return sp;
> }
>
> +static int
> +s390_address_class_type_flags (int byte_size, int dwarf2_addr_class)
> +{
> + if (byte_size == 4)
> + return TYPE_FLAG_ADDRESS_CLASS_1;
> + else
> + return 0;
> +}
> +
> +static const char *
> +s390_address_class_type_flags_to_name (struct gdbarch *gdbarch, int type_flags)
> +{
> + if (type_flags & TYPE_FLAG_ADDRESS_CLASS_1)
> + return "mode32";
> + else
> + return NULL;
> +}
> +
> +int
> +s390_address_class_name_to_type_flags (struct gdbarch *gdbarch, const char *name,
> + int *type_flags_ptr)
> +{
> + if (strcmp (name, "mode32") == 0)
> + {
> + *type_flags_ptr = TYPE_FLAG_ADDRESS_CLASS_1;
> + return 1;
> + }
> + else
> + return 0;
> +}
> +
> struct gdbarch *
> s390_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
> {
> @@ -1869,6 +1900,12 @@ s390_gdbarch_init (struct gdbarch_info i
> set_gdbarch_long_long_bit (gdbarch, 64);
> set_gdbarch_ptr_bit (gdbarch, 64);
> set_gdbarch_register_bytes (gdbarch, S390X_REGISTER_BYTES);
> + set_gdbarch_address_class_type_flags (gdbarch,
> + s390_address_class_type_flags);
> + set_gdbarch_address_class_type_flags_to_name (gdbarch,
> + s390_address_class_type_flags_to_name);
> + set_gdbarch_address_class_name_to_type_flags (gdbarch,
> + s390_address_class_name_to_type_flags);
> break;
> }
>
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [RFC] s390-tdep.c: Define address class functions for s390x
2003-01-31 20:19 ` Jim Blandy
@ 2003-01-31 21:07 ` Kevin Buettner
0 siblings, 0 replies; 4+ messages in thread
From: Kevin Buettner @ 2003-01-31 21:07 UTC (permalink / raw)
To: Jim Blandy, Kevin Buettner; +Cc: gdb-patches
On Jan 31, 3:14pm, Jim Blandy wrote:
> This looks like a pretty straightforward definition of a new address
> class. Is that right?
Yes.
> Since we only have one target using this facility at the moment, this
> might be premature, but I wonder if it would be worthwhile to provide
> standard, table-driven versions of *_address_class_type_flags_to_name,
> and *_address_class_name_to_type_flags, so that a target could simply
> say:
>
> static address_class_table s390_addr_classes[] = {
> { "mode32", TYPE_FLAG_ADDRESS_CLASS_1 },
> { 0, 0 }
> };
> ...
>
> use_address_class_table_in_gdbarch (gdbarch, s390_addr_classes);
>
> which would install the right methods. Or something like that.
I think this idea is worth purusing once we have more than one target
using the address class facilities.
> Maybe even s390_address_class_type_flags could be handled by the same
> table. I haven't thought it through.
Yes, I agree. For s390, the byte size would be used. However, some
other target my used the address class constant from the DWARF2 info
or, perhaps, some combination of the two. That's why I think it'd
be worth having a couple of other targets under our belts before adding
this machinery.
Kevin
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC] s390-tdep.c: Define address class functions for s390x
2003-01-27 23:26 [RFC] s390-tdep.c: Define address class functions for s390x Kevin Buettner
2003-01-31 20:19 ` Jim Blandy
@ 2003-02-03 20:46 ` Kevin Buettner
1 sibling, 0 replies; 4+ messages in thread
From: Kevin Buettner @ 2003-02-03 20:46 UTC (permalink / raw)
To: gdb-patches
On Jan 27, 4:26pm, Kevin Buettner wrote:
> The default pointer size for s390x is 64 bits. The patch below causes
> 32-bit pointer types obtained from (dwarf2) debug info to be stored as
> a separate type and to be qualified (in gdb's ptype output) as
> "@mode32". [Patches to gdbtypes.[hc] and dwarf2read.c which implement
> address class support have already been committed. They need to be
> revisited, however, because in the course of testing out this patch, I
> found a bug. More on that later...]
>
> Comments?
>
> * s390-tdep.c (s390_address_class_type_flags)
> (s390_address_class_type_flags_to_name)
> (s390_address_class_name_to_type_flags): New functions.
> (s390_gdbarch_init): Define ADDRESS_CLASS_TYPE_FLAGS_TO_NAME,
> ADDRESS_CLASS_NAME_TO_TYPE_FLAGS, and ADDRESS_CLASS_TYPE_FLAGS.
Committed.
With regard to the bug noted above, I've posted a patch which fixes it:
http://sources.redhat.com/ml/gdb-patches/2003-01/msg00790.html
Kevin
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-02-03 20:46 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-27 23:26 [RFC] s390-tdep.c: Define address class functions for s390x Kevin Buettner
2003-01-31 20:19 ` Jim Blandy
2003-01-31 21:07 ` Kevin Buettner
2003-02-03 20:46 ` Kevin Buettner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox