This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC/RFA] Cleaner handling of character entities ?
> > 2006-05-05 Joel Brobecker <brobecker@adacore.com>
> >
> > * dwarf2read.c (read_base_type): Set code to TYPE_CODE_CHAR
> > for char and unsigned char types.
> > * ada-lang.c (ada_is_character_type): Always return true if
> > the type code is TYPE_CODE_CHAR.
> > * c-valprint.c (c_val_print): Print arrays whose element type
> > code is TYPE_CODE_CHAR as strings.
> >
> > Tested on x86-linux, with GCC 3.4 (dwarf2, stabs+), GCC 4.1 (dwarf2).
> > No regression.
> >
> > What do you guys think? Wouldn't that be a step forward?
>
> I really suspect this impacts the existing producers in some way,
> though I don't know exactly how. You should take a look at the most
> recent Modula-2 patch, and the discussion around the previous posting
> of it, which contained very similar changes (conditionalized for M2).
Thanks for the pointer. I think I found the actual discussion, which
started in Feb. Here is the message from Jim expressing these concerns.
http://sources.redhat.com/ml/gdb-patches/2006-02/msg00396.html
He only says that a discussion about this lead you to stick with INT
as opposed to CHAR for C at least, and the resolution was to use CHAR
only for Modula 2. It would have been nice to have a pointer to the
actual discussion so we could remember the reasons for this, but it's
not important.
It looks like the Modula-2 patch has been approved, but not applied
yet. But I can make the same modification in dwarf2read.c regarding
the type code for character types, so that Ada follows Modula-2's
lead. Then the changes in c-valprint.c become obsolete, I believe.
We would be left with:
* dwarf2read.c (read_base_type): Set code to TYPE_CODE_CHAR
for char and unsigned char types of Ada compilation units.
* ada-lang.c (ada_is_character_type): Always return true if
the type code is TYPE_CODE_CHAR.
Would that be OK?
Thanks,
--
Joel
PS: Testing with -gstabs+ where we do end up with the char type being
defined as an int did not reveal any regression with both the
official testsuite and our internal testsuite. Being a curious
little bugger, I can't help but wondering what the problems are.
Darn curiosity!